Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplified circuit #40

Open
JimZam opened this issue Sep 11, 2018 · 3 comments
Open

Simplified circuit #40

JimZam opened this issue Sep 11, 2018 · 3 comments

Comments

@JimZam
Copy link

JimZam commented Sep 11, 2018

Good morning. Probably it has nothing to do with the new circuit (as far as I know the only modification is the connection between P1_2 an State). In xbridge 2.43 to 2.47d I have no problems with sleeping and wake up, but the wixel takes two minutes to sleep after sending a package to the phone: "waiting for ack" From 2.47e to 2.48b xbridge loses packages and doesn't wake up as expected, but it always sleeps after sending a package and receiving the ack from the phone. Could it have something to do with the new circuit? Should I remove the State wire?
As always, thank you so much for your work and help
Regards

Edit: probably it has to do with my previous issue...

@JimZam JimZam closed this as completed Sep 11, 2018
@JimZam JimZam reopened this Sep 11, 2018
@jstevensog
Copy link
Owner

Hi Antonio2001,
If the wixel was "waiting for ack" for two minutes with v2.33-2.47d, it says to me that there was an issue with the RxD line. A common issue.
Since 2.47e, and now 2.48b get an ack, that seems to be solved now.
Note that 2.48b does a few things differently. Firstly, the wixel wakes and scans for packets but DOES NOT turn on the HM-1x module. It will only turn on the HM-1x module when it has a packet to send.
This is because the protocol now sends a "ms ago" field to tell the phone how long ago a packet was received, so there is no need to make the connection BEFORE a packet is received, as was the case in pre 2.48b code. So, that at least may explain why it is not waking up as you expect.
I am more interested in why it is not receiving packets in 2.47e and 2.48b code. The State wire will not impact packet capture at all.
In 2.48b, even if the code does not get an ack from the phone, it will be storing packets in a buffer to send the next time it wakes. So really you should not be losing packets.
Packet loss could only be due to some issue with crystal stability, or damage to the wixel antenna. I have my production bridge and two development bridges, and all three capture packets very reliably.

All I can suggest right now is that you check all solder joints and make sure they are good.

Also, can you please send me output captured in PuTTY of the bridge over say 30 minutes? It will be much easier for me to try and determine what is happening.
Cheers

@JimZam
Copy link
Author

JimZam commented Sep 12, 2018

Good morning jstevensog. I'm afraid I can't send you the output, PuTTy stops working once the xbridge sleeps, the terminal freezes. I have read it can be due to wixel drivers or faulty wixel. I have made all the comprobations you said in another post with BL Scanner and the bluetooth module seems to be genuine, maybe the wixel is damaged :-( I'm not good at soldering, I have two bridges (one with the classic circuit, always on) and I had problems to find someone who could solder them for me, but I'll buy a new wixel and try to replace it (get replaced, I mean)
Thank you so much for your help

@jstevensog
Copy link
Owner

jstevensog commented Sep 15, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants