This is an awesome project!!

[saewoonam]

A group of my colleagues have started something very similar:
https://github.com/saewoonam/ble_adv_covid

We started with BT dev boards to develop the software... And, we are now trying to build our own custom open-source hardware. We should collaborate where it makes sense. We are assembling a few prototypes now (~20) that we will try to field test with robots.

My colleagues and I are mostly in Boulder, CO. But perhaps we could arrange a short web conference call.

We want to see an open-source inexpensive solution to encounter tracing to serve people who don't want to use their cell phone. We think this could be a large set of people.

[bunnie]

Hi! thanks for your interest. Our design is open source and you are welcome to use it!

Let us know if you have any specific questions or things you need help with!

[saewoonam]

Ditto for you. We are also making our design open source. We haven't gone through and edited the licensing info yet...

I am curious about whether you have a strategy on whether you have decided on some kind of protocol for the ultrasonic signals? We are in the middle of discussing adding this capability.

[bunnie]

For the ultrasound, we plan on trying an FSK protocol first. We already have a version of it working (over a wire) in a product we did a while a go: https://github.com/chibitronics/ltc-os/blob/master/orchard/esplanade_demod.c

In full disclosure, the ultrasound feature was a request made by NLnet to include into our system; personally, I have skepticism around the physics of ultrasound propagation in real-world environments limiting the utility of this mechanism, but the general technique has sufficient upsides around privacy and power consumption that it's probably worth exploring despite the technical risk. At the very least, we'll get some hard facts around what can and can't be accomplished in a real-world setting. And at the very least, the system can do BLE, which will definitely work, but has some issues around privacy, power, and determinism around proximity.

Also, I wanted to call out that we're protocol-agnostic in our system -- our goal is to provide a concept platform that protocol implementers can use as a reference for their great ideas. It looks like you're also using Circuitpython, so it seems like it may be possible your protocol layer would also run on our hardware, which is great!

[saewoonam]

Actually, we have been coding C because I wanted to try to fit the code on devices that can't support circuitpython and bluetooth at the same time... But, I would love to switch to circuit python... It would make coding much much easier.

[xobs]

Our goal is to go the other way: Start out on Circuit Python, and then move to smaller devices if ultrasound proves the way to go. As you say, it's easier to get started on.

We've been working with the Circuit Python project to add Simmel support. In particular, we have basic AES integrated, and we've been stabilising low power support. The next (and potentially most architecturally difficult) module to integrate will be the I2S driver which will be used to read from the microphone.

[saewoonam]

Did you choose I2S because it was simpler to interface... What about a PDM microphone? It is simpler from a hardware but more complex on the signal processing side. But, I have a gut feeling there may be clever algorithms to do FSK decoding.

[saewoonam]

Anyway, this is awesome that you guys are working in this direction. I have c-code working using Zephyr that integrates bluetooth advertising, scanning, and storing encounters to the flash (same chip as you are using). You are welcome to use it, or I can help you port it to your device...

[bunnie]

Did you choose I2S because it was simpler to interface... What about a PDM microphone? It is simpler from a hardware but more complex on the signal processing side. But, I have a gut feeling there may be clever algorithms to do FSK decoding.

There's an I2S interface built into the NRF52833, so in theory this is one of the simpler ways to do it. Picked I2S because it bypasses a lot of thorny analog design issues around the mic (vs. going to an ADC input on the NRF). PDM could also work but since our part has a native I2S interface the actual hardware complexity is lower (although we do have to write an I2S driver, tbd how awful that is).

[xemmanuel]

Hi guys, we are working in the French StopCovid project:
https://www.linkedin.com/pulse/copsonic-join-stopcovid-task-force-tracing-french-app-emmanuel-ruiz/?trackingId=lQ5TV8A7Qk%2B4bwjDKLTmbg%3D%3D

Your token is very cool and we are interested in talking with you because we have been contacted for a project in Europe like yours. My email is [email protected]

https://youtu.be/5IUrAio5AS4

Best Regards.