Dont you have to develop your own firmware for the Fanstel? If and when you do so, there will be no problem to use it to pick up Ruuvi packages.
A quick Dongle update:
Two new firmware projects (ESP32 + nRF52) have been started in cooperation with Offcode Oy.
Electronics are progressing well. Prototypes are aimed to be ready by the end of this year.
First mechanics design drafts are ready and will be published later.
Stay tuned for more info 
4 Likes
Thanks for the update Lauri. waiting for something to test
Iāve lots of Ruuvitags in production in different places, I can be a tester volunteer!
Great. I want tested it!. Congratulations
This looks awesome. Will you be able to flash the dongle with different Firmwares like you can the Ruuvitag? If so, what are you thinking about including as firmware?
Iād also love to see the dongle have the ability to broadcast BLE packets itself (I may be biased on this). What are your thoughts on that?
We plan to include bootloader in both ESP32 and nRF52, so you can upload your own code to both without any special equipment. Thereās no plan for other firmwares at least yet, but usually porting FW from one nRF52 board to another is really quick unless new drivers for external sensors have to be coded.
1 Like
Hey,
I found this really late, but this sounds great! While reading all the posts some things came to my mind.
-
Related to this: āAdvertisement data is sent via MQTT with topic āRuuvi/{MAC_ADDRESS}/ā.ā
Is it fixed this way? I could think that it would be beneficial to determine the MQTT topics freely and utilizing parsing of the BLE messages. For example I might want to have different topics for different device types or physical locations or message content. -
Regarding what messages to forward. I would like to see filtering where any part of the BLE message could be used for whitelisting or blacklisting messages.
For both 1 & 2 maybe regular expressions would be powerful and simple enough? Is it user friendly enough is another question.
-
Bigger topicā¦ I would love to see this device function also as Bluetooth Mesh node with at least Proxy and Relay features, but ideally also Friend feature. I donāt know how easily it would be possible, but It would be great to create a network using e.g. Bluetooth Mesh light bulbs or any other devices and then have this or some of these gateways to get connection to Internet and have custom use cases utilizing the network.
-
Form factorā¦ I think the USB dongle is great. Itās easy to find USB chargers and even that is often not needed as USB sockets are āeverywhereā. I think I would also benefit from PoE, but price is higher priority!
-
For reference check: https://en.minewtech.com/gateway.html
https://usermanual.wiki/MINEW-TECHNOLOGIES/G1
Here is also screenshot of the service config page:
Then some questionsā¦
What kind of rough price point are you thinking of?
Do you have idea when the device could get out at least for testing?
Minew device has a lot beefier CPU and runs a really lightweight Linux if I recall correctly. Weāre limited by the ESP32 which makes such comprehensive configuration impractical.
Thatās good idea for sure, weāll keep it in mind for future development
We initially considered PoE and Ethernet, but it would add quite a lot to the cost as the isolation transformer and PoE negatiation component tend to be expensive.
The dongle will be priced competitively, weāre aiming to have first prototypes in 2019 and will notify in this thread once theyāre available for larger audience,
I see. Do you see any configuration possible even a static one where I could have each gateway post to predefined topic?
Looking forward to that!
A topic prefix configurable over the hotspot configuration interface was at least discussed at some point. Even if itās not on first version we can consider adding the feature.
It does make subscribing to tags by their MAC address a bit more difficult, as the user needs to wildcard-subscribe to gateway topics to get the tag data unless they know which GW has the specific tag.
Iād say it is then up to the user. They may keep it same for each GW, but if they have 100 installations (e.g. sites or tenants) where each have 20 GWs, it would be nice to have topic per installation. A bit of hierarchy.
Hey,
I noticed that some source code was added to the Ruuvi github.
In regards to https://github.com/ruuvi/ruuvi.dongle_nrf.c, what SDK will this be using?
Hello,
SDK15.3
1 Like
Awesome thanks
Ruuvi Gateway update:
All the comments are welcome. If youād like to be a beta tester, find instructions on the blog post.
OK sorry going to be honest here. While I understand the practicalities, the antenna for me is an immediate issue.
In certain installations where it can be hidden its likely ideal. Where it is going to be visible it looks like a childās toy and cloverleaf antenna are notoriously fragile.
Perhaps there are options (rubber dipole, or internal) depending on its intended location ?
OR can the stub be reduced in length and the antenna be covered by a dome, this would retain the performance of the antenna type and improve its appearance and susceptibility to accidental damage
Awesome work.
The gateway is looking great.
It looks like the antenna would be changeable so depending on the client they could then purchase an antenna to suit their needs. Could you confirm that this will be the case?
Will there be a way to flash the nRF52 module? Will it be done via SWDCLK and SWDIO connection or are you planning on DFU functionality?
The antenna is detachable, so itās possible to use other types of antennas as well.
Yes
Only SWDCLK and SWDIO is planned for now. Adding BLE bootloader just in case wouldnāt be too much of work though 