I must have the worst luck ever… I’ve ordered a couple more f9p modules without issue until today. Plugged in the new, out of the bag, GPS-RTK-SMA board, updated the firmware, installed my configuration, and 15 minutes later, the leds on the board ( power,rtk,fence) started to go dim and then comms disconnected. i really dont what what is causing this? Is it just me or has this happened before to others? I can connect to the f9p again as we speak, and it will work fine for 2-3 minutes and then it drops comms and will fail. I really like this product, and would like to continue to use them.
I currently have 2 of them in the field guiding farm equipment with sub inch accuracy!!!
this morning i came back down to the office and plugged the suspect f9p back into usb. It was working flawlessly for approx 30-40 minutes. I was almost thinking it was going to be ok and worked itself out… but then i could actually hear a faint sizzle sound. I did the lip test and found the regulator to be fairly warm and then shortly after, the fence and rtk light begin to fade and blink randomly. Seconds later the comms dropped off and then it was game over. I plugged it back in again after a few moments and this time it took 2-3 minutes for the same thing to happen.
My 5v voltage source for the base stations are the 110v-5v Ac/Dc adapters i buy from sparkfun, and the 12v-5v Dc/Dc is a UBEC from a rc speed controller. The f9p gets its own 5v supply from this module, and any other 5v items in the box get their own as well. (nothing in series pulling amps through the f9p). i was even concerned this morning that the flux ive been using to solder with was somehow conductive and was causing a short across the board. tested it and was not the culprit.
i have another new(in the bag) f9p, but wont use it until we can get to the bottom of this issue.
all that is in this new antenna module is the f9p, bluesmirf, ttl-rs232 level changer. the ground and 5v both split off the ubec (rc speed controller) power supply. one to the gps, one to the level shifter.
i was even concerned this morning that the flux ive been using to solder with was somehow conductive and was causing a short across the board. tested it and was not the culprit.
This is actually very possible. It may not be causing this particular issue but could cause you issues elsewhere. I recommend removing all the flux from your soldered joints just to eliminate potential issues down the road.
Did you guys want this one back for further testing? I have this one plus 1 more with the same issue. Is there some additional testing you would like me to do? Should I just building an A LA Carte version with a built in 12v to 5v regulator? I need to start ordering these in bulk soon, but would like one more system in the field for testing this summer. so far, the other 2 units have been working almost flawlessly in the field. The one base station was even powered up since last fall and made it through 3 months of minus30 weather:)
The 3.3V regulator failing (especially with heat and sizzling!) is usually a sure sign that it has been over-voltage’d or reverse-polarized. I strongly suspect the BEC / ESC. Maybe it outputs 5V most of the time, but what does it output on start-up - especially with no motor connected? Could it be outputting more than 5V - however briefly?
Please walk us through the history of this latest board. When did you first start to see issues? Had it only been powered by USB when the issues first appeared? Or had you already connected it to the BEC? There is no diode protection between the USB 5V and the 5V breakout pad on that board. If you have USB and BEC 5V connected at the same time, they will try to fight each other. I wonder if that could be contributing to an over-voltage event?
Hi, i have the same issues and unfortunately i don’t have an extra module. It was working flawlessly through either I2C or UART1, but suddenly without any changes made, the comms won’t work.
For clarity, at first i was using the gps module using I2C and last time migrated to UART1 both comms working great. After the testing returns good data, i haven’t touch anything and didn’t sure if i have closed the connection yet or not but i think it’s still powered on 24/7. After less than a week, i came back and found out that the comms returns error. I have tried to check it through USB and u-center it doesn’t show any errors even shows it receives some satellite data. Checking further using UART1 and I2C give no difference. Using i2c, i have tried to double check the address on u-center and scanning through the i2c address using esp32 but to no avail.
I am trying to debug the problem and the debug output from Sparkfun GNSS V3 Library is below
UART1 Debug:
createFileBuffer: Warning. fileBufferSize is zero. Data logging is not possibl.
getVal key: 0x10730001
Sending: CLS:CFG ID:0x8B Len: 0x8 Payload: 0 0 0 0 1 0 73 10
sendCommand: Waiting for ACK response
waitForACKResponse: TIMEOUT after 1100 msec.
getVal: sendCommand returned: Timeout
begin: isConnected - second attempt
getVal key: 0x10730001
Sending: CLS:CFG ID:0x8B Len: 0x8 Payload: 0 0 0 0 1 0 73 10
sendCommand: Waiting for ACK response
waitForACKResponse: TIMEOUT after 1100 msec.
getVal: sendCommand returned: Timeout
begin: isConnected - third attempt
getVal key: 0x10730001
Sending: CLS:CFG ID:0x8B Len: 0x8 Payload: 0 0 0 0 1 0 73 10
sendCommand: Waiting for ACK response
waitForACKResponse: TIMEOUT after 1100 msec.
getVal: sendCommand returned: Timeout
I2C Debug:
createFileBuffer: Warning. fileBufferSize is zero. Data logging is not possible.
begin: isConnected - second attempt
begin: isConnected - third attempt
I2C Scan: Just reports no i2c address found
From the debug output, it seems that the comm is dead but i can’t think of the reason why. And why USB connection doesn’t affected?
When i first open the package with the board, i update the firmware to 1.32, the configure reciever with my saved settings. then i wire in a correction source to the uart2 (either bluesmirf or sik 915mhz radio). following this, i wire a max3232 ttl-rs232 logic level shifter so that i will have comms with the rover on serial. Last, i connect the 5v regulated plug from a new speed controller to the 5v pin on the board. Once power is supplied to the board, i verify that the module is translating correctly through the 3232, via a serial/usb converter and i watch a few nmea strings come though with arduino serial monitor. If any settings need to be changed, i will disconnect the power from the module/receiver, and connect usb to make changes. after this, i plug the unit back in and let it sit on the test bench for an hour before i close it off with a desiccant pack and the lid. then its into a package and out the door. this particular unit had lost its comms when i came back to take it of the test bench. I checked the 5v supply coming from the bec and it was solid. Ive been running the becs in 200mph+ rc planes in competition for several years as they power the radio receiver. I’ve never had an issue with them with over voltage. never lost a plane because of receiver failure… just a bad pilot haha
Can you post a link to your MAX3232 level shifter? You said it gets 5V power from the BEC. That’s slightly weird. I would have thought it needed 3.3V - unless it has an on-board regulator?
The SiK radio should be 5V power, 3.3V UART, so no concerns there.
Please post your configuration file here - “Upload attachment”. We’ll take a quick look just to make sure there’s nothing weird in there.
If you have a schematic / wiring diagram, please upload that too. It might trigger that “light bulb” moment.
As an alternative to the BEC, I used all Sparkfun Components in this unit. Everything in this unit worked great for 15 minutes. then the led’s started to dim and the serial and bluetooth dropped out.
Im really hoping you can see something wrong in this photo.
Thanks for the new photo and info. Still no light bulb moment I’m afraid.
If you run the MAX3232 at 5V, its “TTL TX” pin will try to drive whatever it is connected to to 5V. On a 3.3V device like the F9P, you’ll be driving current through the clamp diode on the UART RX pin. But the UART pins have 33Ohm resistors in series, limiting the current to a few 10’s of mA. Very unlikely to cause harm.
But in this system, you’re running the MAX3232 at 3.3V - from the RedBoard Artemis - so you should be absolutely fine.
The RedBoard Artemis has a LM1117 regulator on it to drop VIN down to 5V. Then a separate AP2112 drops that 5V to 3.3V. If I’m reading your photo correctly, the AP2112 on the RedBoard is providing power for the Artemis, the ZED-F9P and the BlueSMiRF (via the Qwiic cable). Together they could be drawing a few 100mA, but it should still be under the 600mA limit of the AP2112.
Officially, you’re back feeding the AP2112 regulator on the F9P board with 3.3V from Qwiic. But we do that all the time. It really doesn’t explain why it failed with heat and sizzling when you connected it to USB.
I’m at a loss Dave. I can’t explain it. Like I said, regulators failing that way is usually a sign that they have been over-voltage’d or reversed-polarized. But I can’t see anything on your photo that would explain that.
Please do upload your configuration file, so we can take a quick look.
the following is my current (in field) configuration. I had to drive out and get the antenna to pull the file. I did a lot of tuning in the field so i wanted to make sure i sent you the correct configuration.
YellowDog:
Your photo shows RX on the serial adapter connected to ground and TX on the GPS connected to ground on the serial adapter?
the tx/rx pins are labeled incorrectly on the translator. It’s not a “never worked before” problem. Its a “works for a while then quits” problem.
Many thanks for the configuration file. You are running at 10Hz and outputting GGA at 10Hz on UART1 at 115200 baud. GSA, GSV, VTG,GRS, at 0.1Hz. GST, ZDA at 1Hz. You are also outputting GSA at 10Hz on USB. That’s a lot of traffic. Maybe you meant this to be 1Hz, like the other USB messages? Also, you have all constellations enabled. That may cause issues for RTK at 10Hz. But none of this explains why your regulators are failing.
I’m not sure what to suggest. To my knowledge, you’re our only customer who’s ZED-F9P boards are regularly failing. It makes me think there’s an issue with the way you are using / powering the boards. But, I’m struggling to figure out what that is. You have been very open and honest, and have shared a lot of information with us. If you’d like to return this latest failing board, we’ll replace it. But I can’t promise we’ll continue to replace boards as you ramp up production. Like I say, to my knowledge, you’re the only customer who’s boards are failing in the way.
Just wanted to show you the very first test unit i built. It has over a year in the field and still purring like a kitten. Definitely not the cleanest build, but its functional. I like the product, and LOVE the support and technical documentation!!! I want to keep running these units if possible. Moving forward, Is there a way we could get all these components build into one PCB via sparkfun before ramping up production? Is there a way I could comunicate directly with you fella’s? Thanks Guys
