Strange behaviors of Facet with "unformatted" SD card

[swells-sfefae]

Subject of the issue

Base and Rover had satellite acquisition problems (number of SIV would not change after power-on and boot-up), communications problems (ESP-Now, telemetry radios not sending RTCM, trouble pairing radios). This is coming from a second-hand source, so details are thin.

Your workbench

RTK firmware versions: v3.9, v4.0

Steps to reproduce

Cannot reproduce. The cause of the problem was described to me as "unformatted SD cards". I don't know if that means wrong format (ext4, RAW, etc..) or no partition table, or the SD cards were in some other weird state. Tried to reproduce using SD with no partition table, but didn't notice any of the symptoms listed above.

Expected behavior

Facet behaves as if no SD card is inserted.

Actual behavior

Satellite signal acquisition is impacted, communications via ESP-Now and Radio port.

[gdt]

I'm having a hard time understanding the intent of filing this issue. Someone, who apparently can't produce a proper bug report themselves, gave a vague report of a problem, without a reproduction recipe, and a conclusion of a cause. There's no explanation of what was on the card, if it were reformatted or removed, or something else. People reading the issue have no idea about pretty much anything, other than someone's system appeared not to work, and that someone jumped to a conclusion.

If there's a path to useful information, it would be good to elaborate.

(I'm not from SF; just a random user.)

[swells-sfefae]

Greg,

I'm an applications engineer from SparkFun, and submitted this issue in response to a customer describing problems over the phone. They weren't able to provide quite a few of the details that both you and I would've liked to be included in the bug report; I posted this as a gateway to more investigation.

If a misconfigured SD card can cause the units to not function as intended, I think it is worth looking into proactively. The correct solution for this may be better documentation, or it may be worth implementing some checks of SD card state in the firmware.

That being said, I did not like the feeling of opening up a GH issue with so little information. I appreciate you pushing to keep the standards for issue tickets high; issue tracking can get quite unmanageable if we let them slip.

[gdt]

Sorry, I mistook -sfefae for the arbitrary letter groups so many people have in github usernames :-) Certainly, if SF wishes to dig into this, that's of course your call. I saw this as a random user report into an open-source project, since that's my normal context.

(As an aside, I think it's great how much software maintenance SF has funded and how much this code has improved. It's very impressive compared to another RTK product from another vendor, which has been hugely disappointing. I might even try to get to run this code on their hardware. As a result I have recommended your products to two people, one of whom has bought one and one of whom is looking at your backorder status :-( )

[swells-sfefae]

No worries, it is really important to have quality controls on GH issues; I think we've both seen the impact of letting those slip.

Thank you for the feedback on this. Open Source is our bread and butter at SFE, and it is great to see people using our stuff! If you manage to get it working on that other hardware, we would be interested in featuring it in one of our project stories on our blog; shoot me a message when/if you'd like to share that project with the world, I imagine many people would love to read about it.

[nseidle]

In general, the firmware should (and I'd argue does) fail safe.

The firmware uses a software detect method to see if a card is present. If it is, it will attempt to mount the file system. If that fails, the card remains marked as offline. I believe the system will continue to try to init the card. This may lead to odd behavior, but I've had plenty of corrupt cards and never saw this type of behavior.

Perhaps the card was successfully being mounted but the config file was inappropriately setup leading to a bad or invalid device configuration.

If this was replicable, we could mitigate it, but it's going to be hard to really do anything at this point. I'm going to close as I think we've recorded the gist of the issue.

If needed in the future, we could permanently mark a card as 'bad/offline' and avoid re-inits. This may alleviate what this user may be experiencing.