tuxphone / CubeCellRepeater

Small repeater node for the meshtastic project.
36 stars 6 forks source link

Feature ideeas #3

Closed ghost closed 2 months ago

ghost commented 3 years ago

Hey, I have some ideeas.

Some people may or may not use a meshtastic device.My use case is that I cannot add a keyboard to the meshtastic software(I don't know to program).However I think it would be cool to be able to repeat non-meshtastic devices data.Your code to set the frequency is verry easy to be ported to other devices.I think that there is a modification to the if(!packet size)(//packet size too small;Non mestastic device)

It would be cool to have a flag REPEAT_NON_MESHTASTIC = TRUE .

Moreover this will allow to send commands to the repeater.You could send a /getinfo lora message and the repeator will send battery details or sensor data.It would be cool to have a template. You can also set repeator settings such as /set REPEAT_NON_MESTASTIC FALSE {"Repeator password"} or change frequency settings without communicating with meshtastic network(If you run commands throught meshtastic, I think other channel members would be able to see the repeator password and intercept the commands on the go...thats why I think its better to send commands outside meshtastic net)

I want to personally mount a small releay on a flag on a top of a small hill that will cover my city.I want to attach a small bmp180 sensor and make the repeater work also with meshtastic but also with my own communication system(Basically 2 TTGO with I2C keyboard and a simple send and receive function).But in order to do that I need to repeat non-meshtastic device signals.

tuxphone commented 3 years ago

Ok. Your personal network is non-meshtastic and non-encrypted? I don't see much problems. Put both nets on the same frequency/spreading factor/code rate - settings and your are good to go.

My code IS blocking "too short" messages right now to protect the serial output from running into problems. What i should do in this cases is blocking serial output, but repeating the package anyway. Will do.

So the only thing you would need is a "send_temp" function which will periodically send temp data to your personal net.

The code right now WILL repeat any package greater than 13 bytes. The "meshtastic" part of my code is the interpreting of the content as a meshtastic packet and output serial data (or OLED) of this interpretion.

What i will do in the near future, is repeating any packet regardless of packet length. If the packet is too short, it will get no interpretation as mesh packet, but a short notice of receiving/resending it.

Would that solve your problem?

BTW: Running your net and meshtastic on different settings (freq/SF/CR) would be a problem, because the lora chip can only scan for packets on a specific setting at the same time. One could "listen" on setting 1 for a time, then listen to setting 2 for a time, but you could lose packets that way. I was thinking about the possiblities of using CAD (channel activity detection) for this, but i'm not sure if it really is a good idea in itself (listening to 2 settings).

ghost commented 3 years ago

Yes, my net is unencrypted non meshtastic but it will have the exactly same frequency settings as the normal meshtastic.This would solve my issue.