sending an image without wifi / envoi d'une image hors wifi

[dimi59]

Hello,
I have a plan to take a photo with a motion detector at the bottom of my garden and have this image sent to my home automation assistant.
I do not wish to send the image by wifi because I will not be under wifi coverage.
I have no problem on the home automation part I can add GW.
My main concern is how to send the image (about 50m) I am not in a hurry to receive it an offset of a few minutes is enough for me.
Of course I would like this system to be as energy efficient as possible because it will be powered by a battery.

Do you have any idea how to transmit my image?
I thought of an ESP32-CAM for taking photos but it only does Wifi and suddenly I can not use it.

Cordially.

Bonjour,
j'ai un projet de prendre une photo avec un détecteur de mouvement au fond de mon jardin et que cette image soit envoyé sur mon assistant domotique.
je ne souhaite pas envoyer l'image par wifi car je ne serai pas sous couverture wifi.
Je n'ai pas de problème sur la partie domotique je peux ajouter des GW.
Mon principal souci est comment envoyer l'image (environ 50m) je ne suis pas pressé de la recevoir un décalage de quelques minutes me suffit.
Bien sur j'aimerai que ce système soit le moins énergivore possible car il sera alimenté par une batterie.

Avez vous une idée de comment transmettre mon image ?
je pensai a un ESP32-CAM pour la prise de photo mais celui ci ne fait que Wifi et du coup je ne peux pas m'en servir.

Cordialement.

[Puneit Thukral]

Very interesting requirement. In the world of amateur radio, this is possible using SSTV (Slow Scan TV ) on frequency bands like VHF or UHF. But then this is not encrypted and anyone with a receiver and hardware can receive and decode these signals.

https://en.wikipedia.org/wiki/Slow-scan_television

Now, if it can be done with NRF24l01 or with RFM69, I do not know. Back in the day, people were sending multimedia over Bluetooth so maybe that works for you.

[dimi59]

ok, thanks

I'm going to watch this but I would also like to make a gateway with the signal to connect it to my wifi.

[Guillermo Schimmel]

Do you have the image already in some standard form? Like png or jpg? Or do you have the raw data?

In any case you can split the data, send it and reassemble. Shouldn't be difficult.

[rejoe2]

@Guillermo-Schimmel It indeed should not be to difficult, but still there are some questions to be addressed:

• Is there any common standard (e.g. mark start and end of transmissions with keywords like "START" or "END") in stream messages (other than OTA)?
• How about multi stream options (different ChildIDs).

Afaik the ony sample transfer code ist this one. Using that as a base, I recently built a (not yet tested) version that most likely will be part of the FHEM integration, so I'd really appreciate some common approach to that topic to not propose a somehow "strange" implementation.
But no answer on that question until now.

[Guillermo Schimmel]

@rejoe2 said in sending an image without wifi / envoi d'une image hors wifi:

@Guillermo-Schimmel It indeed should not be to difficult, but still there are some questions to be addressed:

• Is there any common standard (e.g. mark start and end of transmissions with keywords like "START" or "END") in stream messages (other than OTA)?

Not that I know of. I'm afraid you are on uncharted territory now.

• How about multi stream options (different ChildIDs).

Afaik the ony sample transfer code ist this one. Using that as a base, I recently built a (not yet tested) version that most likely will be part of the FHEM integration, so I'd really appreciate some common approach to that topic to not propose a somehow "strange" implementation.

This is a nice implementation.

If it were me, I would try to seek compatibility with MQTT, I mean send the images in some form that they could be decoded by any subscriber to my broker.

But regarding header, start/stop and child id I'm afraid you are going to make your own.

Thanks a lot for this effort, I think it would be useful for a lot of us.

But no answer on that question until now.

[BearWithBeard]

I don't know if I would want to stress my MySensors network with sending large amounts of data. Don't you want to limit the throughput of the data-sending node to not flood the network, so that the gateway and possibly any repeater on the way can still handle messages from and to other nodes?

I took some measurements a while back and found out that a send() function in my NRF24 network takes about 80ms to complete on average.

To transmit a 5 megapixel image with moderate JPEG compression, we might have to transmit about 400 kb of data, which has to be split into at least 16k messages due to the maximum payload of 25 bytes. This would take 53 minutes at 5, or 33 minutes at 8 messages per second. A low quality, low resolution picture with only 50 kb would still take 4 to 7 minutes.

You may also have to verify that every single message has been correctly received by the gateway with an echo.

On a different note: 50 meter of range doesn't sound too crazy for WiFI. If we sit in the far edge of our garden, which is about 25 m away from the nearest access point located in the center of our basement, our phones receive a good signal. And phones aren't known to have awfully good WiFi antennas.

I see that the ESP32-CAM has an IPEX connector. Have you tried to attach an external antenna to it? Don't forget to move the 0 Ohm link / resistor from the PCB trace antenna to the IPEX connector if you do so. Maybe try with a good quality, high gain (directional) antenna first, before you look for alternative methods, because I think that the high data rate WiFi provides is better suited for this task than MySensors. You would receive the image within seconds after taking it and the device can go back into sleep mode. I think you could easily get several months worth of battery life out of the ESP32 sending a bunch of images per day if you manage to get the deep sleep current low enough.

I have no idea how good this one is, but it may do the job:
https://www.banggood.com/Wemos-10dB-Directional-Antenna-For-TTGO-ESP32-ESP07-ESP-WROVER-p-1332910.html

[rejoe2]

@BearWithBeard: Wrt. to nRF I'm absolutely with you. But nRF isn't the only transport layer available, e.g. I'm more or less exculisvely using RS485. In such a setup, also no repeater is needed for (theoretical) distances up to 1.200m.
So beside the fact, this isn't really needed in alsmost any case, I'd really appreciate having a working common approach to the problem.
Additionally: that might include allowing much larger chunks of data sent on each transmission on suitable transport layers at RS485, CAN (got stuck, see here) or (maybe) PJON to get a better overhead/payload ratio.

[rvendrame]

@rejoe2 if you have to run a wire to the place where the camera will be installed, you could use CAT-6 regular ethernet cable. That would carry TCP/IP signal and could also carry power (via POE). And you could use any ordinary IP-camera...

[rejoe2]

@rvendrame Apart from the distance question I'm completely with you. Nevertheless I'll try to get that working It's already coded, so why not test it out? If it's not working or not used by anyone: no problem. I just wanted to avoid setting some kind of standard that might be somehow wrong.