LoraNet

The firmware and software

At first we wrote some testing code to test the communication between two Lora_devices and between mobile and Lora_out via BLE. We found out that maximum payload you can send and receive between two lora device is 255 bytes at time at Spreading Factor 7 and ~51 bytes at Spreading Factor 12. You might be thinking why only 255 bytes when SF is 7. The answer is that the register which hold the length of data is 8-bit. So the text greater than 255 byte, gets truncate itself. Anyways, to solve this problem we divided the text data into separate chunks of 200 bytes(safe side). And send one chunk at a time sequentially and simply receive sequentially and store in buffer to get final text data.

While testing our lora devices we were receiving some json data which was not sent by us, turns out another group was also doing lora based project and they were sending json data. Both theirs and ours lora had same configuration. To prevent this problem we designed our own custom packet. Every chunk we had header id RITU in the name of Ritushwar Neupane and RITUEND as marking the end of total chunk. And at the receiver side we parsed header ID(first fout bytes). If it is matched to RITU then read next bytes else discard.

//RITU+chunk1   ] first packet
//RITU+chunk2   ] second packet
//RITUEND       ] end marker

//chunk1+chunk2=actaul data

void  sendToLoRa(String  response)
{
if  (response.length()  >  0)
{
mode  =  TX_MODE;
setMode(mode);
delay(100); // Increased delay before sending
int  len  =  response.length();
int  totalChunks  =  (len  +  CHUNK_SIZE  -  1)  /  CHUNK_SIZE;
for  (int  i  =  0;  i  <  len;  i  +=  CHUNK_SIZE)
{
String  chunk  =  response.substring(i,  min(i  +  CHUNK_SIZE,  len));
String  fullPacket  =  "RITU"  +  chunk;
Serial.print("Sending chunk ");
Serial.println(fullPacket.substring(0,  min(10,  (int)fullPacket.length())));
LoRa.beginPacket();
LoRa.print(fullPacket);
LoRa.endPacket();
Serial.println("Chunk sent");
delay(500);
}
delay(500);
Serial.println("Sending END marker...");
LoRa.beginPacket();
LoRa.print("RITUEND");
LoRa.endPacket();
Serial.println("END marker sent");
Serial.print("Complete response sent: ");
Serial.println(response);
delay(100);
mode  =  RX_MODE;
setMode(mode);
}
}

Code for implementing chunk system and adding header_id and end marker.

After figuring out these basics we decide to implement three feature.

1. The walkie-talkie

Ability to message from one mobile through Lora_device like walkie talkie but in text. For this feature non of the Lora_decive need to connected to the wifi. You simply take the both Lora_device far from each other and connect it to mobile phone via BLE and then start communication.

2. Simple GPT(AI)

Using Lora_device to enable to prompt simple question to LLM like chat gpt or gemenie. For this feature Lora_home device need to be at home connected to wifi where as Lora_out device will be far from home connected to smartphone to prompt the LLM and get simple text answer.

3. Simple mail

Ability to send email to anybody even if you don't have internet. The setup is same as Simple GPT feature. This is very useful in case of emergency.

In order to implement these feature we need a custom mobile app to communicate with Lora_device. So our another team mate Prashant Bandari and his agent developed a desired app which looks like this...

The app is connected to ESP32 via BLE and it only send text data to ESP32. ESP32 doesn't know that received text data belogs to which feature itself. The app should encode some respective feature id so that ESP32 can parse it and find out what respective action to take at receiver end(Lora_home). After experimenting tons and rewriting logic again and again on both side we finally to a specific conclusion.

Figure: Final data packet design.

As you can see in the image above, the mail feature has MAIL as header id, then we simply update our logic to if first four bytes is RITU or MAIL then only read next byte else discard. Mail feature has three different packet design for recipients name, subject and body because we don't use conventional way sending email. We need to send the info like recipients name, subject and body one by one sequentially.Then after that Lora_home device the put it all together and send mail. So to find out which text in mail is body or subject or recipients name, we implement their separate id.

These header_id and feature_id are attached by the app itself. Therefore, the Lora_out device need not add any overhead it simply passes the data to Lora_home which parse the data and take respective action. Moreover, the data receive by Lora_out from is mostly less than 255 bytes so no chunking of data is needed which reduces complexity.

Figure: Flow chart of Simple GPT freature

The figure shows the complete data flow of the Simple GPT feature and it is pretty much self explanatory.

Figure: Testing feature