No sir, its both.
I need a bunch of tags in a field that has a mobile phone mast about 50mtrs away and no mains power.
Connection to a wifi network is not possible so cellular 3/4G seems the only way I can get the data out remotely.
Without mains power available, our product is not a good fit. Something that is much lower power with cell data support makes sense. This Rigado product might be a commercial grade option: https://www.rigado.com/products/iot-edge-as-a-service/ They advertise cell data support to.
Hope the info helps.
Heh thanks, Mjanke.
It seems to me there is still something of a missing link here and tbe use of short range BT tags in the field literally, in a field, will not be feasible until that link is made.
Cellular hats are available for Rpi etc and with the current collector, Influx/Grafana solution the tags can be deployed anywhere there is cellular connectivity (most everywhere in the UK) now and the data can be accessed, again with a device with celullar access…
The issue is the hats have mulit-functionality and are therefore costly and have relatively high power requirements, a 2amp supply at times.
If strkes me if a device could be made with functionality reduced to the minimum we need for the level of data transmission at say 10 or 15 min intervals over cellular connectivity, the power needs could be met with a battery/solar charger set up.
That was my wish when I backed Ruuvi on Kickstarter and we still apparently have that missing link today.
In general, we use RPi and Beaglebone devices for prototyping only. Their quality (along with available accessories such as enclosures) is not quite up to commercial or industrial standards.
For the use case that you are suggesting (15 min upload frequency), I suspect that a low-power gateway with good power management support (to sleep in between BLE and cell comm periods) would last for months from a larger format, off-the-shelf rechargeable battery (20AHr - 30 AHr). Without doing a power budget, on the fly I would expect 2 - 4 months of use. Really, it will vary dramatically on how much data is sent and how frequently.
Of course setup of solar would address required battery replacement or recharge, but it would also add cost. I won’t comment on options or price as I am not familiar with solar tech for these kinds of installs.
If the Rigado offering (or any other) does not support this kind of system, something custom could be developed.
Hi Guys,
I have written some code for RUUVI-Dongle based on esp32. Please go to the following link in order to access the code.
Please go through the readme.md file for more details about what this project does and how to test the code using esp32 dev-kit.
I am struggling with a small issue of TLS error while connecting to AWS. I hope your feedback would surely help us fix this issue sooner.
2 Likes
I was thinkiing more of battery power in the 2000 mah 2cell lipo area and a corresponding sized solar panel.
Its the cellular bit that needs the power apparently.
I did some further work based on @rhr407 code, http://github.com/shmuelzon/esp32-ble2mqtt and http://github.com/tonyp7/esp32-wifi-manager .
The esp32-ble2mqtt and esp32-wifi-manager are forked and converted into esp-components, and the main project is based on @rhr407’s work. Sources can be found at https://github.com/ojousima/ojousima.esp32_blegw.c . Right now the MQTT server is hardcoded playground.ruuvi.com, I use MQTT.fx to subscribe to the MQTT data.
Please check it out and let me know how the look and feel is. @rhr407 What kind of attribution you’d like on the project files? Please let me know and I’ll add copyright details or open a pull request with the changes.
1 Like
Data collected with ESP32 is now flowing 
4 Likes
Hi, I have a SPI sensor to interface to Nordic chip and need connection to 6 GPIOs+Vdd+Gnd. Is it possible using the grove sensor? Or I would need to design my own PCB?
From a firmware perspective, will I need to create and flash two firmwares, one for wifi chip and one for the nordic chip, or it will be possible to manage wifi connections, send http requests and so on, through the nordic chip only?
Do you have an estimated date for first samples?
Thank you
Is this related to the Dongle project? The first Dongle revision (discussed above) uses ESP32, not nRF52.
The firmware project discussed above is built on ESP32 (a combined WiFi + BLE chip).
Hi everyone,
This is super interesting topic and from customer point of view I’m interested in the schedule.
What’s the planned schedule for Ruuvi Dongle? Are we talking about months or years before I could order one?
I know I could solve my use case with gateway made out of Raspberry Pi, but the problem is I don’t believe enough on my technical skills. Of course I could find a maker to build the gateway and that might be my path.
Thanks for a great forum and nice products! Kudos to Ruuvi Team and Community!
Cheers
Is there any code for ESP32 we could test? Very early stage version of code is okay, if it is at least semi-official and may lead to official version later. I’m mapping out technologies which we could use in very interesting environmental sensor project in Helsinki area this and next year.
We’re currently evaluating ESP32’s BLE scanning performance using development kits and haven’t designed Ruuvi Dongle hardware (yet). You can order one today:
We already chatted about this in Telegram, but for the benefit of others coming across the thread. Unofficial code is at https://github.com/ojousima/ojousima.esp32_blegw.c, we’ll move the code under Ruuvi once it’s at readier stage.
My biggest issue when I tried to compile Otso’s code was wrong esp-idf version. The code compiles with v3.1, but not with v4.x version, which gets installed if you clone the code from github. In addition, if you use --recursive switch when cloning, all those submodules will be in wrong version and checking out esp-idf v3.1 after initialising them won’t downgrade them.
I’m not an expert in this topic, but here is how I finally got esp-idf environment working:
git clone https://github.com/espressif/esp-idf.git
cd esp-idf
git checkout release/v3.1
git submodule init
git submodule update
pip install -U -r docs/requirements.txt
git describe --tags --dirty
-> v3.1.4-55-ge83bdf62c
There was also issues when esp32-ble2mqtt was compiling, but I’ll get back in them later.
1 Like
A Dongle update!
After prototyping with the ESP32, we’ve now started to build custom electronics. I’m working with its schematics as we speak.
Main features are:
- nRF52 to listen BLE messages (!)
- ESP32
- WiFi
- USB
- Sensors (TBD)
- Ruuvi Connector expansion port
- Easy operation
- All open-source
Main reasons for adding an nRF52 to listen Bluetooth messages are to have a
- better antenna and
- 100% duty cycle.
ESP32 has a shared antenna between WiFi/BLE and ESP32 modules have teeny-tiny PCB antennas.
Ruuvi Dongle will have a far more better BLE antenna and it’ll listen continuously in order to catch all the signals coming from nearby BLE beacons. ESP32 will provide a WiFi connectivity.
If you’re interested in contributing the firmware projects, give @otso a shout.
2 Likes
By default, the Dongle listens nearby broadcasting Ruuvi products and therefore it won’t transmit anything. AFAIK, the article you’re referring to is about legacy Bluetooth devices (not BLE).
ETSI EN 300 328 defines EIRP at 1 MHz bandwidth to be max 10 dBm. This means that in Europe, 10 dBm is the max tx power for a BLE transmitter.
I thought you were developing 2-way communication between the Dongle and the tags.
I know that the link is not about BLE but it applies the same logic (class 1 and 2).
The BLE limit by definition is +10dBm, but the NRF52 can already transmit at +8dBm.