-
Notifications
You must be signed in to change notification settings - Fork 49
rx radio listening interferes with gps updates #60
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
Comments
Sounds like a great project! this brings back memories of trying to use a GPS with the RFM9x and I recall having similar issues. In my case, i just stopped trying to receive and found it worked fine as long as I just sent packets. If I recall correctly, the issue was that the GPS expected gps.update to be called more frequently than was occurring. I will try to reproduce this and see If I can get anywhere with it. It's been a long time since I looked at it. Have you tried reducing the timeout even further -- say .1 seconds? |
I ran your code on my feather_m0_rfm95 and it seems to work OK
edited to add -- here is what I am receiving on another board -- with some diagnostics
|
Thanks for replying so quickly! Yes, that is the board that I using and I am running CP 6.1.0. I did try going really low with the rx receive but I was still having the same issue. Last night I tried sprinkling the I tried looking into why the gps would take some time to initialize and give 0's in the dates, angles, etc, but I couldn't really find the documentation. What causes the I thought about just having the dog's unit transmit and not receive, but I would really like to be able to put it into low update mode (if he is close to running out of battery and not heading back to me, I don't want it updating at a high rate and run out of battery). I ended up starting a new script with most of the same components, and for whatever reason it is performing better with the updates. It still seems to delay the loop longer than the timeout I put on the rx...but as long as I'm receiving my strings in time, that's ok. I put in there that if it receives "q", change mode to 300 second updates instead of 5 seconds, and if it receives "s", then send a small status packet. This script seems to be working ok, except that it runs for about 15 minutes and then there is an error with receiving corrupted data (I may have had crc off then...maybe that will fix it?). The error I am getting is Is there any way to ignore bad data to keep the board from crashing if it receives a corrupted packet? Here is the updated script (just all in code.py now, not using a class):
|
Occasional noise packets are a fact of life for me To trap a particular exception you could do something like this:
That should go back to the top of the While True loop and listen for another packet. Take a look at other uses for the try/except statements in Python. That can be very helpful in avoiding crashes. I'll try to run your updated code see how it works. Sounds like you are making great progress. |
Excellent, thanks for that, I'll write it in! Yes, all of the examples and documentation in the Learn section of the website have helped me move forward quickly. I just ordered the hardware 2 weeks ago and started out with Arduino. I was doing ok trying to adapt other people's code, but customization was getting cumbersome for me since there was so much I didn't understand, so I started looking at CircuitPython last week. I've only ever coded with R, and Python is so much closer to that language. If there's something that if I don't understand in Python, I can usually find the answer by looking it up and understand it (NOT the case with C++). I'll carry on testing and let you know if I see anymore unexpected behavior. Appreciate your help. |
@dewalex I have been running your code and it is working quite well with occasional dropped packets when I use the default radio configuration. When I use the parameters you specified, I seem to be dropping more packets. My radios are quite close together at this time. < 1 meter apart. I was curious how it is working for you. I have not done a lot of experimentation with the radio parameter settings. Edited to add: This enables an automatic "ack packet" handshake and automatic retries.
|
@jerryneedell Thanks for your reply. I increased the Spread Factor and reduced the Bandwidth to try to get more distance, and in testing before writing this code I have gotten best results from the max Spread Factor 12. The problem is that it takes a couple of seconds to send, which would really interfere with any incoming commands. The settings that I have above increase the Spread Factor but don't block everything for too long, although, I could not have a timeout of 0.5 and still get good GPS data (they were repeating for 25 seconds at a time). When I lowered to 0.2 timeout, I was getting good reports every 5 seconds. This means that I have to send it commands ("s" for a status update or "q" for a change in report interval) 3 or 4 times before it actually receives them. That's not so much of a problem as long as it sends the status or tells my Rx that it got the interval command and is changing modes. I'll add in the ACK and let you know if it makes the process take long and interferes with the |
One other issue I am having is that my Rx is the M0 Bluefruit Feather. I would like to find a way to stream incoming data to my computer or phone. I'm not sure if I am just out of space with the rfm9x and bluefruitspi libraries being stored on the chip (I have 4kb still left to work with), or if there is an incompatibility with the two libraries. Both libraries are from the 6.x bundle. If it is an incompatibility, we can split this into a new issue thread. Just adding the import like so
gives this error:
The line 112 for me is just this:
|
It is very unlikely you will be able to use the bluefruit library and the gps library on an RFM9x_M0. The is just not enough RAM. The line 112 reference is in the adafruit_rfm9x library code, not your code,py but that may not be very meaningful. |
Oh wait ,I was confused, this is not the GPS unit, but it is a bluefruit Feather M0 -- there you have to install the rfm9x library and the bluefruit library - the RFM9x is not "frozen in " like it is for the RFM95_m0 board. Again, there just may not be enough RAM for both the rfm9x and bluefruitspi libraries. |
ah - I do have an M0 Bluefruit -- It'll try it on mine ad see if I can get anywhere with it. Are you using the RFM9X featherwing ir a breakout with it? |
What version of CircuitPython did you put on the Bluefruit M0 -- I am able to load all the libraries using the "Adalogger" .uf2 file.
|
Yes, sorry, should have mentioned that it is the RFM9x featherwing. Dogs unit is: RFM9x M0 + GPS featherwing, my unit is: Bluefruit M0 + RFM9x featherwing. I put the adalogger uf2 on the bluefruit m0, using this example: https://learn.adafruit.com/munny-lamp/code-with-circuitpython. Thanks for giving it a try, it would be really cool if I could pass the data over bluetooth so I can eventually be able to use the tracker with a phone to see the locations being sent. Here is my Rx code, if you want to use that. On the bluetooth side, ive just gotten as far as importing the library and trying to read the spi.
|
What's the concept behind "frozen in" libraries? Does that mean that for libraries that are frozen in, I don't need to add them to the lib folder on the chip? |
@jerryneedell The version of CP on the Bluefruit M0 is also 6.1. |
Yes -- If they are listed when you run I am using the 6.2 beta versions but there may not be a big difference -- you can get the latest from the downloads pages for the boards https://circuitpython.org/board/feather_m0_adalogger/ to see if they perform any better. |
Ugh! this is messier than I thought. I'll spend some time seeing If I can get anywhere with the Bluefruit board. It may take some experimenting with some "custom" builds. I'm not overly optimistic that it will work but I'm happy to experiment with it over the next few days. An nRF5280 board would probably be far more well suited since it has much more RAM and supports the bleio module. |
I am able to run your code on my feather_m0_bluefruit with the latest build of CircuitPython for the Adalogger. I have not tried 6.1 I even went so afar as to uncomment the line
and it still runs. Encouraging. |
I just upgraded the M0 to the 6.2 beta and I am no longer getting the error. |
I've been trying to test the Bluefruit connection as well. I have found that importing the rfm9x library before the Bluefruitspi library also helps avoid memory allocation errors. |
@jerryneedell The tx code (note: erase the node addresses unless you have set them on the receiver unit):
|
It looks like you have it working well for your application. I learned a lot from this discussion. Good luck with your project. |
Thanks for your help |
I am very new to circuitpython. What I am trying to make is basically a much simpler version of the GlitterPos example: a lora gps using the Feather M0 lora chip + GPS Featherwing to make a dog tracker that sends out my dog's location every 4 seconds. I would like to add a feature where I can send the dog's tracker a message and have the update interval change from 4 seconds to 5 minutes.
The trouble that I am running into is that when I have rx listening (even at a timeout of 0.2), the gps data is ruined and it sends 0's in the dates, satellites, etc, and sends the same timestamp for about 15 to 20 seconds before grabbing another.
Can anyone tell me why this interference is happening?
Ideally I would like for the radio to be able to receive data while sending other data out, but I don't know how to make those happen concurrently and don't think Ive read that there is a possibility of parallel processes with this hardware. Either way, I didn't think that a short listening timeout would do this to the gps data though.
gpos.py:
code.py:
The text was updated successfully, but these errors were encountered: