microReticulumTbeam/exercises/204_established_identities/Codex_1.md

2.9 KiB

Prompt: Referencing /usr/local/src/microreticulum/microReticulumTbeam/exercises/203_microreticulum_link_ping_pong, you are to create a new 204_established_identities (I already created the directory) building upon Exercise 203. You probably should copy Exercise 203's files, except the README.md since I have already started a draft of Exercise 204's README.md. You can, of course, copy portions from the README.md in Exercise 203 into the 204 as appropriate.

Please review Exercise's 204 README.md -- it is a preliminary draft that contains information about identities created for the 7 units. Exercise 204 is to utilize these already created identities. Do not worry about secrecy for the identities, they were simply created for exclusive use in this exercise. Please modify the platformio.ini (copied from Exercise 203 as) so that each build has its correlated identity information.

You need only compile two unit's build, BOB and CY and load same and monitor via a serial interface. I'll compile the other 5 and then load the binaries as needed -- this is to save time and reduce the thought time your have to utilize and which is allocated to me in 5 hour chunks.

Please use the OLED facility. At startup there should be a splash screen withe "Ex 204 v. XX" -- you will use the Python script for versioning of this execerise so at start-up, I can verify which version is loaded.

Please use the disciplined clock approach which means if the RTC has not been disciplined within the last 24 hours, then the unit needs to obtain time from satellites and therefore needs to be taken outside. If a unit has been disciplined in the last 24 hours (using the saved clock file appoach we have used in other exercises), then the unit does not need to be exposed to satellites and my proceed transmitting and receiving messages.

We'll eventually have event written to a log file, but that is a nice-to-have feature we'll implement once we've proven that messages are being transported by intermediate units.

Please configure all units as "transport".

The first iteration of this exercise is to succeed in having BOB and CY exchange messages over LoRa. Once that works, then for a second iteration, what we'll do is prevent BOB's LoRa from being received by CY so that BOB's message must come through another unit in 2 or more hops. We will use hard-coded blocks to simulate the out-of-transmission-range state between BOB and CY for Lora thereby forcing intermediate units, e.g. DAN, ED, FLO or GUY to transport the packets. And then for the utlimate version of this exercise, we'll cause blockages among the units such that for BOB to commmunicate with CY, their packets will have to be transported through several intermediate units.

Messages sent and received should have iteration numbers so we can detect dropped packets. As each unit learns of other units, then each unit should send a "Hi from [unit name]" and the 7 units