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.

Sign up for GitHub

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

Jump to bottom

doing some small tests and reporting #17

Closed
jerabaul29 opened this issue Jan 10, 2023 · 23 comments
Closed

doing some small tests and reporting #17

jerabaul29 opened this issue Jan 10, 2023 · 23 comments

Comments

@jerabaul29
Copy link
Collaborator

@jvoermans there is still quite a bit to code, but if you have time for a small test today and letting me know how the serial over USB output looks like and how the files on the SD card look like that could be great :) . Will need a GPS reception to work. Of course no hurry, if it does not fit for you to test today another day is fine :) .
@jvoermans
Copy link
Owner

I was just about to open an issue. There is a problem with connecting to GPS I think.
Normally, the fix LED on the GPS breakout blinks every second or so while trying to get a fix, but now only one blink during start-up, that's it. Serial output (below) it says it can't wakeup GNSS. Any ideas what it could be? I tried with the general adafruit sketch and I did get GPS output that way. Are we using the EN pin for sleeping, cause I haven't connected that one...

OpenMetBuoy-v2021 | https://github.com/jerabaul29/OpenMetBuoy-v2021a
Compiled: Jan 11 2023, 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
git branch: DUMMY | commit ID: DUMMY
compiling hostname: DUMMY | username: DUMMY
Chip ID: 15245007187966232465     
***** all user configs start *****
use_usb: 1
file_start_modulo_seconds: 600    
***** all user configs end   *****
ERR: timeout GNSS acquisition
sleep for 900 seconds

@jerabaul29
Copy link
Collaborator Author

Thanks for the report, I will look into this :) .

@jerabaul29
Copy link
Collaborator Author

(just to make sure, you have good GPS reception when using the other sketch?)

@jerabaul29
Copy link
Collaborator Author

(when you show serial outputs, can you add the timestamps? :) If using the Arduino IDE serial viewer there is an option for showing timestamps; in platformio, I have added an extra parameter to platformio.ini that should enable timestamping, let me know if it does not show up :) ).

@jerabaul29
Copy link
Collaborator Author

About the GPS problem:

  • I do not use the enable pin, should not come from this

  • but I do use the standby / wakeup functionality to try to save a bit battery by "software sleeping it" (since the GPS consumes up to 30mA continuous when active, which may be like 10x more than the rest of the whole logger together, switching if off when not needed sounds reasonable). That may be the root cause. I will re-read the documentation a bit and add a few delays, if you can try again and let me know if this fixes the issue this would be great :) .

@jerabaul29
Copy link
Collaborator Author

(I have pushed a first fix attempt, so will be curious to see how it goes with latest version :) )

@jvoermans
Copy link
Owner

Yes, I used the main-branch so see whether GPS is working, and it does.

I now get the following output, still doesn't seem to grasp the GPS:

08:01:41.618 > WindInput logger | https://github.com/jvoermans/Wind_Input_V1
08:01:41.618 > Compiled: Jan 13 2023, 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
08:01:41.618 > git branch: DUMMY | commit ID: DUMMY
08:01:41.629 > compiling hostname: DUMMY | username: DUMMY
08:01:41.642 > Chip ID: 15245007187966232465     
08:01:41.650 > ***** all user configs start *****
08:01:41.651 > use_usb: 1
08:01:41.651 > file_start_modulo_seconds: 600    
08:01:41.651 > ***** all user configs end   *****
08:01:41.663 > init GPS, get first fix
08:06:43.920 > ERR: timeout GNSS acquisition
08:06:43.920 > sleep for 900 seconds        
08:08:14.110 > wakeupERR: cannot .wakeup GNSS
08:08:15.261 > ERR: cannot .wakeup GNSS
08:08:15.887 > ERR: cannot .wakeup GNSS
08:08:16.512 > ERR: cannot .wakeup GNSS
08:08:17.138 > ERR: cannot .wakeup GNSS

However, this time the GPS breakout does seem to have a fix. So during the 'init GPS, get first fix' the LED was blinking with long gaps, so it should have a fix.
During the 90 second sleep, the behavior of GPS doesn't change, still long pause LED blink (so maintains fix).
During the 'wakeupERR: cannot .wakeup GNSS' the GPS breakout seems to reset again or something, quick LED blinking. So it is actually waking up I assume? It looks like with every ERR message it resets, cause blinking is a bit odd during that period of time...

@jerabaul29
Copy link
Collaborator Author

Ok, thanks, I will double check the code. These standby / wake-up routines seem troublesome, interesting.

@jerabaul29
Copy link
Collaborator Author

Never had so much trouble using a GPS before ^^ . I will try to find some components around me to test. Should have time to look into this over the weekend, I let you know when you can test again.

@jerabaul29
Copy link
Collaborator Author

I got my hand on a chip thanks to a friend; I really do not understand what happens, it looks like I can receive data from the GPS module just fine, but that I cannot send any data to it; I opened an issue at sparkfun/Arduino_Apollo3#477 . First time I use the Adafruit GPS with the Artemis Redboard, I did not expect this would cause so many troubles :( .

@jerabaul29
Copy link
Collaborator Author

A possible (ugly) fix: just let the GPS run freely all the time, without trying to switch it between standby not standby etc. That means that it will draw 30mA all the time, instead of going to low power mode when not needed (which is most of the time), so will need much more battery than actually needed. What is the typical deployment time you expect / aim for?

@jerabaul29
Copy link
Collaborator Author

(note that this may be annoying but is likely not missing critical; the consequence is that with 1 D battery you may get 1 week of autonomy instead of a couple of months, but I guess you can always put 3 or 4 D batteries if needed...)

@jvoermans
Copy link
Owner

jvoermans commented Jan 13, 2023 via email

@jerabaul29
Copy link
Collaborator Author

Aaah, do you have some I2C SF GPS available under your hand? If so that would be much better indeed :) .

@jerabaul29
Copy link
Collaborator Author

We could use the EN pin, but then you will need to use the battery, so extra work to prepare, one more thing that can go wrong etc. But if you like better keeping the Adafruit GPS and adding the external battery, fine to keep the Adafruit GPS then :) .

@jerabaul29
Copy link
Collaborator Author

(and will need to add an extra wire and a pull-down I think so that the state is consistent when off :) ).

@jvoermans
Copy link
Owner

We can go back to the I2C SF GPS, it is in the lab, not at home. I'm just a bit turned off with the I2C problems I had. Nothing more frustrating to get a 'GPS not found' message, even though Qwiic cables are used to connect it.

I prefer to keep the Adafruit GPS therefore. With pull down you mean have the extra wire also connected to ground with a resistor?

@jerabaul29
Copy link
Collaborator Author

Ok, when did you have I2C issues? (just curious, the Adafruit GPS is fine to me using the EN pin and the battery :) )

Yes, exactly - using a high R resistor to "fix" the voltage of the EN when no output is provided by the digital control pin. I will have to check regarding the pull ups / down needed - the idea is that if the MCU goes to sleep, there will be no power output on the pin. I think there is already a pull up (so that it is on by default), so we would need a pull down that is stronger (so it is off by default). But I am not sure, I will check tomorrow :) .

@jvoermans
Copy link
Owner

Two months ago or so. It sometimes just can't find the I2C, then disconnecting reconnecting it does find it, but next time it doesn't. Tried different qwiic cables and also tried a second I2C GPS. I think the problem could be anywhere, from the cable to connectors of the controller and GPS. Either way, such robustness issues are a bit difficult to handle especially to cope with in testing phase. Perhaps then can be solved with soldering the pins.

I'm not sure if you remember, but I had similar problems with the IMU and qwiic when building the first OMB. When moving the IMU too much while keeping the AGT fixed, it suddenly hangs, suggesting a glitch with I2C. Of course, in the field this is not a problem, as the artemis and sensors move equally, thus the qwiic cables or connections are not being tested that much...

@jerabaul29
Copy link
Collaborator Author

I have added support for the EN control, and removed the annoyingly not working standby instructions, so it should work now :) .

Could you give it a try again, and let me know how it goes (if you can capture the serial output with timestamps and provide in a file that would be great :) ).

Note that you will need to add one wire (great if you can add on the schematic :) ) between pin 2 and GPS EN. I think (may change in future) that there is no need for pulldown, but will be checked later on.

@jvoermans
Copy link
Owner

Sorry, late response. I will test today!

@jerabaul29
Copy link
Collaborator Author

No worries :)

@jvoermans
Copy link
Owner

Output after GPS fix, sleep and on again:

10:17:07.192 > $GPRMC,231708.000,A,3747.9561,S,14457.6844,E,0.00,77.42,190123,,,D46
10:17:08.182 > gnss received NMEA end
10:17:08.183 > gnss NMEA parsed valid
10:17:08.184 > gnss NMEA is RMC
10:17:08.184 > gnss fill output fix
10:17:08.184 > $GPRMC,231709.000,A,3747.9561,S,14457.6844,E,0.01,77.42,190123,,,D46
10:17:09.190 > gnss received NMEA end
10:17:09.190 > gnss NMEA parsed valid
10:17:09.191 > gnss NMEA is RMC
10:17:09.191 > gnss fill output fix
10:17:09.191 > $GPRMC,231710.000,A,3747.9561,S,14457.6844,E,0.01,77.42,190123,,,D4E
10:17:10.182 > gnss received NMEA end
10:17:10.182 > gnss NMEA parsed valid
10:17:10.182 > gnss NMEA is RMC
10:17:10.183 > gnss fill output fix
10:17:10.183 > ERR: timeout GNSS acquisition
10:17:10.368 > sleep for 900 seconds
10:18:40.125 > wakeupgnss get good averaged fix
10:18:40.126 > gnss turn on
10:18:40.126 > gnss enable high
10:18:40.229 > gnss start serial
10:18:40.339 > gnss send commands
10:18:40.542 > gnss done turn on
10:18:40.642 > gnss get first fix
10:18:40.642 > gnss start grab uart output
10:18:40.643 > $GPRMC,231711.000,A,3747.9561,S,14457.6844,E,0.00,77.42,190123,,,D4E
10:18:40.644 > gnss received NMEA end
10:18:40.645 > gnss NMEA parsed valid
10:18:40.646 > gnss NMEA is RMC
10:18:40.646 > gnss fill output fix
10:18:40.647 > $GPRMC,231712.000,A,3747.9561,S,14457.6844,E,0.00,77.42,190123,,,D4D
10:18:40.648 > gnss received NMEA end
10:18:40.649 > gnss NMEA parsed valid
10:18:40.650 > gnss NMEA is RMC
10:18:40.650 > gnss fill output fix
10:18:40.651 > $GPRMC,231713.000,A,3747.9561,S,14457.6844,E,0.01,77.42,190123,,,D4D
10:18:40.652 > gnss received NMEA end
10:18:40.652 > gnss NMEA parsed valid
10:18:40.653 > gnss NMEA is RMC
10:18:40.653 > gnss fill output fix
10:18:40.653 > $GPRMC,231714.000,A,3747.9561,S,14457.6844,E,0.01,77.42,190123,,,D4A
10:18:40.656 > gnss received NMEA end
10:18:40.656 > gnss NMEA parsed valid
10:18:40.657 > gnss NMEA is RMC
10:18:40.657 > gnss fill output fix
10:18:40.658 > $GPRMC,231715.000,A,3747.9561,S,14457.6844,E,0.01,77.42,190123,,,D4B
10:18:40.659 > gnss received NMEA end
10:18:40.660 > gnss NMEA parsed valid
10:18:40.660 > gnss NMEA is RMC
10:18:40.660 > gnss fill output fix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jerabaul29 @jvoermans