search

jvoermans / Wind_Input_V1

Sketch for measuring pressure and IMU using Platformio
0 stars 0 forks source link

doing some small tests and reporting #17

Closed jerabaul29 closed 1 year ago

jerabaul29 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

jerabaul29 commented 1 year ago

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

jerabaul29 commented 1 year ago

(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 commented 1 year ago

About the GPS problem:

jerabaul29 commented 1 year ago

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

jvoermans commented 1 year ago

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 commented 1 year ago

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

jerabaul29 commented 1 year ago

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 commented 1 year ago

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 https://github.com/sparkfun/Arduino_Apollo3/issues/477 . First time I use the Adafruit GPS with the Artemis Redboard, I did not expect this would cause so many troubles :( .

jerabaul29 commented 1 year ago

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 commented 1 year ago

(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 commented 1 year ago

Sorry about that. We can always swap back to the I2C GPS from Sparkfun. What about the EN pin? Or doesn't that work? From the tutorial it reads like it can be easily turned off. Then can put a coin battery behind GPS to keep the memory?

On Fri, 13 Jan 2023 at 22:50, JR @.***> wrote:

(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...)

— Reply to this email directly, view it on GitHub https://github.com/jvoermans/Wind_Input_V1/issues/17#issuecomment-1381748865, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKIGDYGM3WKPGFSWVI7DGOTWSE6RVANCNFSM6AAAAAATXICMKM . You are receiving this because you were mentioned.Message ID: @.***>

jerabaul29 commented 1 year ago

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

jerabaul29 commented 1 year ago

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 commented 1 year ago

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

jvoermans commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Sorry, late response. I will test today!

jerabaul29 commented 1 year ago

No worries :)

jvoermans commented 1 year ago

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