Nothing, it's totally vanilla VOXL2. Our code is all user space python we run manually, and this thing hasn't run really since the beginning so it has the minimum.
Also this time I ran Voxl-inspect-cpu every so often and it shows the processors all running in the 500-800 mhz range nothing being warm.
One last thing, I checked the power via px4-listener battery_status this time and I noticed that it has a field "warning: 3" No idea what that means.
And yes I have three or four APMv3's and have tried them all over time, this is the only time I've ever seen a warning and none of them will keep this board running.
I was able to repeat the testing with the new cables you sent (thank you), same result. It'll run for an hour or so and then hard stop. After it dies, interrupting power has no effect, the board is one light only. My hunch is that after some extended period of time without power, it will become bootable again.
Seems like a terrifying problem because it'll result in whatever it's flying just dropping out of the sky.
I've attached more pictures and this time attached a volt meter to show the battery's at a healthy 12.3V after the failure.
Just got back from some field testing up North. I see you sent you sent out an extra cable so I can try that and report back today. But the failure behavior is that it runs for awhile on that battery and then just fails and will not restart for any reason. Always well above 12V.
I want to add some clarification since this unit has already been RMA'd once and checked out A-OK. I may be the one making the error.
This board is in no way accessible to ADB. It is not connected to any peripherals of any form, the power supply and battery are both supplied direct from ModalAI. There is no physical damage to the board.
On the ModalAI documentation portal, here: https://docs.modalai.com/voxl2-leds/
it indicates that there are three LED's and that the one closet to the power supply is called "D1" and that it is called "Power Good LED" and that if the light is out, that "indicates either 3P3 VREG or emulated VBAT are not good"
Is that true? And is it correct for me to interpret that as if the LED is out, the power on the board is therefore not good? It seems like plain english, but I want to be super sure since you guys worked so hard to QC the board once and again to QC it again on RMA.
Now I have also taken photos of the system today, can we concur that the D1 light is in fact out? and that the components connected to it are only ModalAI components and there are absolutely no peripherals attached that might cause a short?
Am I doing something wrong here? Can anyone spot whatever mistake I am making?
just for clarity, only DS1 is lit now, and that's a solid green, all other LED's out.
Sorry for the late reply, I ended up going straight back to 12V from the wall plug to the APM v3 and then let that power the board for the time being.
The only problem is that it ran find on the bench for a week and then abruptly died yesterday. Green light on DS1 but the other side of the board has a 3V good light and that's out and now the board won't get to the ADB stage.
I'm having a hard time driving direct 5V power into the J4 connector, it looks like the eFuse keeps tripping and the board never boots. I'm supplying 5.07 volts from a bench top power supply, directly bypassing the APM v3. I've got 6 amps of available current.
Does anyone have any tips for direct power without the APM v3?
Another update, got it working to 25hz on an M9N with all constellations running simultaneously. Duty cycle wasn't bad on 115,200, 12 milliseconds of transmission every 40 milliseconds. Just in case anyone ever comes across this thread in the future.
Update, got it working, turns out you guys broke auto baud.
Okay, first of all, I didn't buy the $49 unit from Holybro, I bought $190 unit from ModalAI. It's been wired differently. I've consulted the U-Blox reference manual for the M8N, a very common chip, and it clearly indicates it will run at 10Hz:
https://content.u-blox.com/sites/default/files/NEO-M8-FW3_DataSheet_UBX-15031086.pdf
Second, you guys forked your own version of PX4 and if I understand correctly made changes to make it work over the Qualcomm DSP on the VOXL 2. Your code branch has its own definitions.h and gps.cpp file implemented and can be found here:
https://github.com/modalai/px4-firmware/tree/main/src/drivers/gps
Third, I did review the PX4 code base for UBX.cpp and it looks to set everything to 5hz, unless it's an F9P for which it sets it at 10hz. It also includes some sort of complaint as a comment about not the author's inability to read a GNSS data sheet and based on the code that follows, a strong possibility that the original author sabotaged the code branch to force minimal update rates as some sort of retribution.
// measurement rate
// In case of F9P not in moving base mode we use 10Hz, otherwise 8Hz (receivers such as M9N can go higher as well, but
// the number of used satellites will be restricted to 16. Not mentioned in datasheet)
int rate_meas;
if (_mode != UBXMode::Normal) {
rate_meas = 125; //8Hz for heading.
} else {
rate_meas = (_board == Board::u_blox9_F9P) ? 100 : 125;
}
On my VOXL 2, I'm trying to get the ModalAI-supplied GPS working at 10hz. According to the data sheet for the M8N, it can be set to 10hz once the constellations are limited to GPS only. I was able to set that param with QGC (and watch the satellite count drop by half), but still stuck at 5Hz.
If it can't be done with the ModalAI supplied GNSS, then who else makes one that will work with the VOXL2?