LoRa remote camera

[faragher]

So, I'm getting old, and my eyes are shot. Even 30-60x magnification (for spotting, can't really shoot over 10x, and irons are great if you're challenging yourself) can't do it anymore, so I built a setup I can armor downrange and watch the target. (I'd do it with the ESP squawking arbitrary frames and using a yagi to pick them up, but esperif gutted their API so now 802.11 "support" is for ethernet only, and a 30 dB antenna with transmit capability on a standard WiFi unit is pretty illegal around here. Rant over. Closed source is the devil.)

Would anyone find any use in this? It'd take a few days to weeks to go from programmer grade to "sure, I guess it's user friendly" and it takes 30-60 seconds for a single frame of 720p-1080p at maximum speed (SF7BW500CR5) and high compression (jpeg quality 50). It only goes up from there (SF8 BW125, my usual setup, takes eight times longer, and SF12 would be a joke)

I honestly think outside of someone unwilling to walk a few hundred yards, it has basically no use case, but maybe it'd be helpful? Reticulum isn't limited to RNode, after all.

[cobraPA]

Sounds like fun... wouldn't a telescope with active cam and a monitor be faster (sitting next to you, not armored at the target?) You can also start running multiple parallel Lora channels for higher throughput, I guess. I haven't seen that done, but the LoraWan multichannel boards could be setup to push more data through, I would think.

[faragher]

That's a really good idea. It would be more expensive and less fun, but probably an altogether better plan. Still, good practice interfacing with a webcam and using Reticulum resources.

The multichannel is a neat idea in a more robust situation (apparently you can overlap different SFs on the same frequency, but I haven't tried) but might me more than this project is worth.

[markqvist]

I'd love to see it if you make it! I did something similar, but much more hacky, a while back. Was just a hack of fswebcam, rncp and rnx and some spaghetti shell scripts to allow me to pull small compressed frames from the dashcam in my car. A more nice and less hotglue-and-hope approach would be pretty neat :)

[faragher]

I am rapidly running out of time to do it right this year, but the software is good and the hardware is all working, so I just need to build an enclosure. I'll get you the code and photos of the prototype if it makes the deadline this year.

[whitecd]

I agree there are applications for this capability.
Options to mitigate LoRA throughput limitations could be:

1. Transmit delta frames or the difference between the current frame and the last frame transmitted. This should result is a reduced data payload if not much has changed in the frame or worse case be similar to a full frame transmission. Approach- periodically transmit delta or full frames in order to update receive side "reference" image and then on-demand transmit delta frame.
2. Use of multiple LoRa channels for uplink: This could be accomplished with "upstream/downstream" LoRA Rx/Tx or multiple downstream radios and a "LoRAWAN concentrator", i.e. gateway card.
3. The gateway card can receive upto 16 independent SF and/or LoRA RF channels concurrently. Depending on the baseband chipset (there are 3 different chips), they can demodulate 8 SF/channel on each of 8 channels at 125KHz BW. In addition, it can concurrently receive at 125, 250, and 500KHz at fixed SF.
4. The fixed SF channel is typically used as a "high(er) throughput backhaul" between gateway cards. There is usually a single Tx per card, but it can Tx at all SF, CF, BW, freq combinations. So, there is a lot of support for SF, CF, and freq diversity (only 125, 256, and 500KHz in BW) available. Thus, a gateway can support all SF/CF combinations across 8 different channels at 125KHz which would allow for a range and frequency diversity. A gateway node could also provide for higher throughput "hopping" between gateways at 125, 250 and/or, 500 KHz (fixed SF).

[faragher]

Good suggestions, but I think transmitting the deltas wouldn't change much, and may even be worse. A lossless image could certainly be improved by sending deltas, but JPEG compression wouldn't produce a consistent image, and since there's already a 90-95% reduction in image size over PNG, I don't believe I could figure out a way to make it effective across use cases. As is, it's designed to only process and send an image on request, so it may not even know what the last stored image is in a multiple-access scenario.

I am intrigued by the gateway card's capabilities, I don't have access to one, and they're way out of budget at the moment, but certainly a good thing to keep in the back of my mind for all Reticulum related designs.