Software Does Not Support I2C GPS on Raspberry Pi CM4 Frog Sensors

[keenanjohnson]

While guiding @pascaljoly through building his sensor, we encountered an issue where his GPS was not connecting.

It turns out that this was an oversight on my part in the past related to how we identify if a Frog Sensor should use the I2C Interface for GPS or USB.

The version 1 frog used a Raspberry Pi CM4 + a USB GPS. Version 2 used a Beaglebone and a I2C GPS. The software (as shown below) uses the processor board type to figure out which GPS protocol to use.

Current Code

https://github.com/Ribbit-Network/ribbit-network-frog-sensor/blob/90d1233d10dffe42723979b90ede3222def8835e/software/co2/co2.py#L67-L70

This doesn't work with V3 as we use a Rasbperry PI CM4 with an I2C GPS.

I was able to get @pascaljoly 's sensor working by changing the code as show below, but we need to determine a proper fix as my code below will break backwards compatibility with V1 Sensors (we still have active v1 sensors on the network).

GPS_SOURCE_MAP: Mapping[Optional[str], GpsSourceType] = {
    "beaglebone-green-gateway": GpsSourceType.I2C,
    "raspberrypicm4-ioboard": GpsSourceType.I2C
}

Options I see to fix this:

• Lock the V1 & V2 Sensors Software releases and only support I2C sensors going forward. This is the simplest, but most limiting in terms of hardware options.
• Make the software smarter to scan both USB and I2C interfaces for a valid GPS sensor in either location. This would be a more ideal fix, but harder software to write.

[mag]

@keenanjohnson n00b here, so probably a dumb question, but is there any way for the environment to pass in the frog's hardware version? given that there is a clearly delineated version history v1/v2/v3, each with a known hardware configuration, it seems that long term it would be really good to have specific information in hand so the script can make the right decisions about how to interface with the hardware. as the device evolves it might be nice to avoid scanning for available hardware, but rather just having code that says "if v3 use I2C", etc.

[keenanjohnson]

Good idea and suggestions @mag !

Balena (our IoT / Fleet Management Provider) does indeed have environment variables that we could pass through to the Docker containers, the question is just how to segment the sensors in a way that makes sense. We could create separate Balena fleets for each Hardware version as there isn't really any way for the hardware itself to determine which version it is. https://www.balena.io/docs/learn/manage/variables/

Perhaps that's the best way to go?

@mpous (from Balena) does that seem like a reasonable plan?

[keenanjohnson]

Now that #182 is merged, I will proceed with creating a new software release for the v3 sensors that doesn't support the old GPS devices for now. I'll create a new balena fleet for each version of the Frog Sensor.

[keenanjohnson]

Now that #183 is completed, a new Ribbit Network fleet for the V3 sensors only has been created here: https://hub.balena.io/organizations/g_keenan_johnson1/fleets/ribbit-network-frog-v3

183 fixes the software and updates the build instructions link accordingly.