Fixes for GPS support on RAK boards - #3051
Conversation
|
RAK12501 (L76K) works RAK4631 on MeshCore 1.16. |
|
You may want to rebase to dev instead. Have you tested the combination of RAK4631/RAK3401 and RAK12500/RAK12501? |
|
@IoTThinks I have tested on RAK3401 with RAK12500 and RAK12501. For the RAK12500, I also tested with I2C disabled (to ensure UART works as well), and I tested in both Slot A and Slot C. I do not have a RAK4631 to test with. re: RAK12501 working with RAK4631 on MeshCore 1.16, I'm pretty confused as to how. Is that running the repeater-bridge RS232 firmware? These appear to be the only variants that define the ENV_INCLUDE_GPS feature flag. I did just see that the RAK4631 config transposes the GPS RX/TX pins which cancels out the fact they are transposed in EnvironmentSensorManager. I'm not quite sure why this is done, but it also seems to be the convention for other boards, so I'll adjust my code to follow this convention too. |
|
GPS 12501 (L76K) works on my RAK4631. Yah, let me push this PR for some of my friends to test on RAK3401 and Rak12500 (i2c). Thanks for the PR. |
This was only configured for a single Sensor Slot anyway
These boards support the RAK12500 and RAK12501 GPS modules.
This board is a RAK4631 derivative (even sharing the same bootloader) and so supports the same features
This seems to have just been a typo. Fixing this allows RAK12500 to work in serial mode, and RAK12501 to work at all. (Both tested on RAK3401)
The previous code only worked by accident. 1. Regardless of which slot the GPS module was present in, it would always be detected as Slot A 2. Slot A reset pin (WB_IO2) overlaps with PIN_3V3_EN. 3. Per u-blox ZOE-M8Q documentation: "In reset state, the SiP consumes a significant amount of current. It is therefore recommended to use RESET_N only as a reset signal and not as an enable/disable." So using reset PIN to control GPS status is not desirable anyway. This commit replaces the faulty reset pin detection and control logic by instead just controlling the 3V3 bus. Note: 3V3 control is disabled on the RAK3401 as this board is most commonly used in the "1W LoRa Booster Kit", and turning 3V3 off would also disable 5V power supply to the SKY66122 PA. Changes tested with RAK3401 with a RAK12500 in both Slot A and Slot C, as well as a RAK12501 in Slot A.
This check was originally implemented in 3e9ceba, but after refactoring needed to be re-added.
I don't really know why this is done, but it's consistent with how other boards are handled so I've restored it for the RAK4631. (And fixed it for the RAK3401)
I have not yet tested these latest changes on real hardware. I'm sick right now. Once I've recovered I'll test this on RAK3401 with RAK12500 and RAK12501. In the meantime, I'd appreciate if someone could test on RAK4631. |
I will test RAK4631 and RAK12501 tomorrow. |
| -I variants/rak4631 | ||
| -D RAK_4631 | ||
| -D RAK_BOARD | ||
| -UENV_INCLUDE_GPS |
There was a problem hiding this comment.
Why we need to exclude GPS here?
GPS codes of other boards is protected by this flag too.
There was a problem hiding this comment.
This kills all GPS code for RAK4631.
There was a problem hiding this comment.
Well, we need to fix this PR to make GPS work for RAK4631.
Currently, GPS (RAK12500 works perfectly on my RAK4631).
Let me see how to fix.
There was a problem hiding this comment.
Oh huh. This should be -DENV_INCLUDE_GPS. I'm not sure how I managed to make this mistake, oops.
|
I have just done some more research.
Impact of WB_IO2 to LoRa:
|
Correct, and I explained this in the PR description above. It is safe to use PIN_3V3_EN to control GPS power state only if other modules do not require the 3V3 rail. For this reason, if an ethernet module is present, or if the SKY66122 is present, my code prevents turning off the GPS. |
I'm not quite sure how I messed this up, I think I must've got -D and -U mixed up. Anyway this is enabled in sensor_base so we don't actually have to enable it here.
|
Btw, this PR doesnot work for RAK4631 yet. Btw, when you do "gps off" and "gps", do you see it still "on, deactivated..."? |
|
Still have hope to have GPS PowerSaving for RAK3401 and I2C RAK12500. :) 
|
If you do not have either the ETHERNET_ENABLE or SKY66122 constants defined, power saving works the same as it always has: by turning off the 3V3 rail. So for the default configuration of the RAK4631, the GPS can still be turned off. I don't think the RAK12500 exposes the correct pin on the ZOE-M8 to allow for proper warm-start power savings. |
| #define EXTERNAL_FLASH_USE_QSPI | ||
|
|
||
| #define PIN_GPS_1PPS 17 //GPS PPS pin | ||
| #define PIN_GPS_TX PIN_SERIAL1_RX |
There was a problem hiding this comment.
Please add
// enables 3.3V periphery like GPS and the IO Module
#define PIN_3V3_EN (34)
Like this
// enables 3.3V periphery like GPS and the IO Module
#define PIN_3V3_EN (34)
#define PIN_GPS_TX PIN_SERIAL1_RX
#define PIN_GPS_RX PIN_SERIAL1_TX
There was a problem hiding this comment.
PIN_3V3_EN is currently missing in RAK4631.
IoTThinks
left a comment
IoTThinks
left a comment
There was a problem hiding this comment.
Please help to fix as in the comment.
I have tested it with RAK4631 + UART 12501 GPS.
Then I will test again after your changes.
Well, a few lines take me quite some time.
Thanks a lot.
| else if(gpsIsAwake(WB_IO5)){ | ||
| } | ||
| else{ | ||
| #ifdef PIN_3V3_EN |
There was a problem hiding this comment.
Except for RAK3401 with 1W with required PIN_3V3_EN at start, most of the RAK boards should have PIN_3V3_EN as INPUT to save power.
This is same as start_gps() too.
And we only need to set it HIGH as this is Power switch, not a GPS RESET.
Please change this:
#ifdef PIN_3V3_EN
digitalWrite(PIN_3V3_EN,LOW);
delay(1000);
digitalWrite(PIN_3V3_EN,HIGH);
delay(2000);
#endif
to this
#ifdef PIN_3V3_EN
pinMode(PIN_3V3_EN, OUTPUT);
digitalWrite(PIN_3V3_EN, HIGH);
delay(500);
#endif
There was a problem hiding this comment.
Except for RAK3401 with 1W with required PIN_3V3_EN at start, most of the RAK boards should have PIN_3V3_EN as INPUT to save power.
And RAK Ethernet (RAK13800) ?
There was a problem hiding this comment.
And RAK Ethernet (RAK13800) ?
I have no idea.
However, putting pinMode(PIN_3V3_EN, OUTPUT); in front is better than without it.
We can call it as many times without impact.
If the boards have PIN_3V3_EN as INPUT such as RA4631 and may be other RAK-based boards, digitalWrite(PIN_3V3_EN,HIGH); will not be effective.
We can see in start_gps(), we also call pinMode(PIN_3V3_EN, OUTPUT); before digitalWrite(PIN_3V3_EN,HIGH);
There was a problem hiding this comment.
Can you link documentation that states that keeping PIN_3V3_EN as INPUT saves power? My understanding is that setting the pin as HIGH shouldn't take power because it's pulled high by default.
re: removing the code to pulse PIN_3V3_EN low for 1s at startup, that code appears to be recommended by RAK so I'm hesitant to remove it. I think it ensures that the GPS is in a consistent state when our code initialises.
There was a problem hiding this comment.
- You can check the code for T096 and see initVariantShutdown.
RAK boards are no magic, but NRF52 boards. They follow the same rules.
- You can check the code for RAK4631 and other RAK-based boards, then imaging what digitalWrite does without pinMode OUT?
Currently, RAK4631 doesnot have pinMode for 3v3 en.
Assume you can turn off LoRa for RAK3401, try to remove pin Mode OUT for 3v3 en.
Then try to bring up GPS via Uart.
There was a problem hiding this comment.
At least, we have to put pinMode OUT.
RAK4631 does not have it.
You can keep the delay or you can explore what are best values.
RAK is a hardware vendor. Their code is sample and on safest side only.
|
The 12501 is powered off via a Waking the GPS when it is powered down is done by sending a 0xFF to it. |
|
Ok, I dove into the wonderful world of RAK pinouts again. The canonical reference for pinouts is here. Confusingly, this doesn't really agree with any of the pinouts listed on any of RAK's datasheets. For example, while the variant definition for the RAK4631 board shows IO2 as being pin 34, the datasheet for both the RAK4631 module and the RAK19007 baseboard shows IO2 as being pin 30. This is also sometimes referred to as SW2, and it then connects to pin 26 on the RAK4630, which appears to connect to pin 1.02 on the nRF52840, but I can't find how that matches up against the value of 34 in the WB_IO2 constant. In theory, all boards that are based on the RAK WisBlock system should use the same pinouts (at least as long as they are using a RAK4631-compatible MCU module, and a RAK19007-compatible base). But when I went to make sure they all agreed, I noticed that some of the GAT562 products were using 33 as their Ok, back to digging. Did I miss something somehow? Well, just as 34 is WB_IO2, 33 is WB_SW1. Looking at this schematic we can see where SW1 comes out of the GAT562 module. (We can also see that P1.02/SW2 connects to a line labelled IO2, which agrees with what we saw earlier and gives us a nice sanity-check) The SW1 line then connects to an external header called "P1.1". It does not go anywhere near the GPS. Looking at the GPS on the schematic (the familiar L76K), there aren't many things connected to it. The only one that would allow turning it on/off is the 3V3_GPS rail. And if we look at the IRLML5203TR MOSFET, we can see that the 3V3_GPS rail is controlled by... IO2! In summary, I am confident that the previous specification of 33 for GPS_EN for the GAT562 family was a mistake, and I have now updated it to use WB_IO2 as I believe was intended. I have also removed further unused definitions for GPS PPS pins. |
Oh wow, that's very interesting! Unfortunately it's unclear what license ZephCore is released under, and MeshCore's MIT license is permissive enough to allow basically any license to be used. So I don't think we can use code from ZephCore unless @liquidraver makes it clear what license ZephCore is released under (which would also require the consent of all ZephCore contributors). That said, now that I know where to look in the ZOE-M8Q and L76K documentation, I might look to implement my own UART GPS optimisations. I believe that may be best be handled in a second pull request though. |
I don’t know how much clearer I can state zephcore’s licence in the repo. It’s in license.md and in all the code headers. |
My apologies, I just looked in the repository root, I didn't think to look in the zephcore directory. Thanks for clarifying! Looking into it a bit, I think the GPS support in ZephCore might have some errors. The L76K protocol used appears to be based on documentation for the L76-LB, which uses a different protocol from the L76K. I could be wrong about this, but I can't find any documentation online suggesting that the L76K supports the $PMTK353 message, or other messages used by ZephCore. |
You are right, I could not verify it actually does anything on L76K, but worst case it does nothing so I left it there to remember :) |
|
More digging, more fun facts uncovered. The RAK12501 is built around the L76K, which does not have any UART codes for power saving / warm off. Instead, based on the schematic diagram this appears to be achieved by cutting power to GPS_3V3/3V3_S while retaining power to 3V3. This is exactly what pulling PIN_3V3_EN low does. So my code currently implements this correctly, pulling 3V3_EN low to turn the GPS into power saving mode if this doesn't interfere with other components that rely on 3V3_S. Time to look into the 12500! EDIT: 12500 can be put into Hardware Backup mode via the same procedure. So for this PR, I think I'm happy. But the 12500 does also support a Software Backup mode via the UBX-RXM-PMREQ which can be activated without deactivating the 3V3_S bus. This would be pretty nice to have, I'll probably try to implement it in a future PR. The ZOE-M8Q NMEA protocol is specified here. |
|
I have tried the UART command to sleep L76K. Saved a few mA only. May be you have more better Uart commands. Nothing beats a full power cut to save 20mA. |
|
As far as I can tell, L76K doesn't have any UART sleep commands. It only has Power Saving state (activated via setting VCC low, V_BCKUP high), which uses 7μA. So 17.993mA savings compared to normal operation. For ZOE-M8Q, typical operational usage is 9-25mA, Software Backup is 20μA, and Hardware Backup is 15μA. So the difference between software & hardware power saving is trivial. |
I think so too. So I tried the UART commands and save a little only.
After this PR, you can explore this opportunity. |
I'm new to C++ so I didn't notice this
- Add `configure` method to LocationProvider, which is called once after GPS init - ublox I2C GPS - enable AssistNow Autonomous feature for faster positioning - UART L76K GPS - Enable use of GLONASS constellation
5 participants
This PR enables GPS support on RAK4631 and RAK3401 boards. It also provides support for RAK12501, which was previously unsupported.
Behind the scenes, it fixes some additional logic errors and slightly improves code cleanliness.
Code changes
Details on faulty reset pin logic
The previous code only worked by accident.
So using reset PIN to control GPS status is not desirable anyway.
Due to the way these logic errors interacted, the RAK12500 sensor was actually able to work correctly in Slot A and Slot C, but for the wrong reasons.
This PR explicitly just controls the 3V3 bus, which was what the previous code was doing by accident.
Note: 3V3 control is disabled on the RAK3401 as this board is most commonly used in the "1W LoRa Booster Kit", and turning 3V3 off would also disable 5V power supply to the SKY66122 PA.
Changes tested with RAK3401 with a RAK12500 in both Slot A and Slot C, as well as a RAK12501 in Slot A. (RAK12501 should work in Slot D too, I just haven't tested it)