Thread Rating:
  • 1 Vote(s) - 3 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Suggestions for the WeatherDuino
#1

Hello together,

I have a few suggestions which would make the WeatherDuino better in my opinion. Since I do not want to claim anything this should only be ideas and I am willing to contribute if anybody finds it also useful.

  • SD Card Logger for the TX Module
    To prevent data loss in any case I would find it great if the TX module would have an SD card data logger. They can be simply bought and be attached to the SPI connector and all data could be logged in ascii at each radio transmission. So if the transmission fails or the receiver is out of power/order you still have the data.
  • TX Module with GSM modem
    Since the Pro2 PLUS runs a webserver with its wifi chip you simply could transmit some data over internet. So if your TX node is far away you could transmit the data via mobile network (if it is available). With the use of a good antenna with a bit of gain it's likely to get a connection in a lot of places.
    I bought myself a SIM 800L and I will do some experiments as far as my prototype gets ready.
  • Software interface for special user modules on TX boards
    Maybe it is possible to add a special software interface to be configured in the config file to call some user specific stuff e.g. a snow height sensor.My idea would be that you can collect some extra data from some other I2C slaves emulated by an Arduino nano to make sure all the data is already waiting to be collected and the main program is not influenced.In summing up a additional device could be added for each sensor which simply calls predefined data from a specific I2C slave and writes it to the corresponding variable.Another intention of me is, to make a calibrated temperature measurement board based on a ADS1220 and a PT100 sensor to get very precise readings with 0.1°C accuracy.
I'm still waiting for all my parts to arrive at my home... shipping from china can last a long, long time  Sad . When finally everything is here I'm planning to create a detailed assembly instruction for the WeatherDuino boards. Maybe it will help someone who is not as much into electronics.

So I'm curious about your feedback.

Regards
Reply
#2

(26-02-2018, 21:02)engolling Wrote:  Hello together,

I have a few suggestions which would make the WeatherDuino better in my opinion. Since I do not want to claim anything this should only be ideas and I am willing to contribute if anybody finds it also useful.

  • SD Card Logger for the TX Module
    To prevent data loss in any case I would find it great if the TX module would have an SD card data logger. They can be simply bought and be attached to the SPI connector and all data could be logged in ascii at each radio transmission. So if the transmission fails or the receiver is out of power/order you still have the data.
  • TX Module with GSM modem
    Since the Pro2 PLUS runs a webserver with its wifi chip you simply could transmit some data over internet. So if your TX node is far away you could transmit the data via mobile network (if it is available). With the use of a good antenna with a bit of gain it's likely to get a connection in a lot of places.
    I bought myself a SIM 800L and I will do some experiments as far as my prototype gets ready.
  • Software interface for special user modules on TX boards
    Maybe it is possible to add a special software interface to be configured in the config file to call some user specific stuff e.g. a snow height sensor.My idea would be that you can collect some extra data from some other I2C slaves emulated by an Arduino nano to make sure all the data is already waiting to be collected and the main program is not influenced.In summing up a additional device could be added for each sensor which simply calls predefined data from a specific I2C slave and writes it to the corresponding variable.Another intention of me is, to make a calibrated temperature measurement board based on a ADS1220 and a PT100 sensor to get very precise readings with 0.1°C accuracy.
I'm still waiting for all my parts to arrive at my home... shipping from china can last a long, long time  Sad . When finally everything is here I'm planning to create a detailed assembly instruction for the WeatherDuino boards. Maybe it will help someone who is not as much into electronics.

So I'm curious about your feedback.

Regards

Hello Engolling,

1. If you had the data logger on the TX directly, you will also need to consider adding the same feature on the AQM board. If ever you are suing several TH units (like I do) I guess it would be troublesome to get the data back from the various TX units in case of transmission failure? Let's say we manage to do it, it would be necessary to compile the different files together to have one single file (with the need to respect the timestamps order for each measure made). In addition, I think the purpose of the recent upgrad Werk did was to actually strengthen the data transmission using the RH library.

2. This solution would imply buying a data only SIM card which would require as many SIM as you have TX units (+ the AQM) as they may not be installed at the same place. What would be the business case to transmit to GSM network (or GPRS, 3G, etc..)? It would be possible but nowadays I believe everyone has a good and reliable wifi connection?
The practical case however, would be to transmit an alert, like some home alarm systems do. This would actually be very handy if you need to monitor some critical measurement - let's say a temperature rising above a certain threshold, or anything that would trigger something. Werk has already provisioned the System with a possibility to customise some code and trigger an alarm; in this case I think the GSM transmission can be useful.

3. I will let Werk comment; that might be a bit challenging but still.

Good luck with the construction of your station. 

Thanks
Zitoune
Reply
#3

Hello Zitoune,
thank you for your feedback. I would like to specify my intention more precise  Smile .

  1. My intention with the data logging function was to have the possibility to retrieve some data even if the wireless transmission fails or the RX Unit is out of power for some reason e.g. severe weather condition.
    Even there is no RTC mounted on the module you still can have relative timestamps. So my idea would be to have a logging function on all TX units as a fall back solution if you you want to recover what happened. So the data may not be retransmitted via radio but saved until somebody collects the SD card to check whatever happened to the system. So there should only be the option to save one way to SD, but not a must.
  2. My idea for transmission via mobile network would be a far away TX station from that you want to retrieve the data. In my special case I'm thinking of a snow height sensor on a hill for example or maybe you could place a AQM on some relevant but far away point. So the idea would be that normal transmission still runs via 433MHz radio but special TX nodes some kilometers away transmit via mobile network. A possible variant would be a system via web request like wounderground has.
    You could simply use some normal sim cards with unlimited low speed data. In Germany such a plan costs about 3 EUR per month.

    Regards,
    engolling
Reply
#4

Hi Engolling,

Thank you for sharing your thoughts and ideas about possible improvements to the WeatherDuino system.

Firstly I should say that I share all the points expressed by Zitoune. I understand what you are trying to do, however I belive that those "features" would be usefull only to a very limited number of users and would imply very significant changes on the TX software and possibly on the hardware too.
I have some doubts that will be possible to implement all the things you are thinking about, using just a Nano as processor on the TX units.

Regarding the question of extend the allowed distance between the TX units and the receiver, I completly understand your point. However, I think there are less expensive ways to achive that, than using GSM. There are 433Mhz amplifiers, and also other types of long distance radios as is the LoRa, which we are investigating since some time.

Regards
Werk_AG

Reply
#5

I don't want to load up Werk with any extra work due to my eccentric wish list but it would be great if is was possible to swap the transmitter module to cover any requirements. But I think for that to be possibility, the modules would need to use a standard packet diagram. And we all know the problem with "standards" today, there's just so many of them to chose from Wink. Otherwise coding to cover all modules would be a big job to say the least and probably use up precious memory space.

I think Werk would remember one site where I would've liked to put a TX unit on. It's on a hill at work and has several tall buildings blocking LOS. The site already has power and fibre optic cable running to it so ideally I would've liked to be able to sent the packets over the fibre and pipe them to the RX unit. I may try this site with LoRa one day.

The another place is my caravan down at the coast. It would've been cool to be able to sent the TX packets over GSM to RX unit on my server back home.

Anyway, for me this could be possible to work around today, if I was wealthier, using TX and RXs units and Raspberrys at each site then deal with uploading the data using good old TCP/IP over fibre optics (on the hill) and a 4G Internet connection (down on the coast).

Anyway guys, that's my thoughts and dreams Smile
Reply
#6

(28-02-2018, 07:38)uncle_bob Wrote:  I think Werk would remember one site where I would've liked to put a TX unit on. It's on a hill at work and has several tall buildings blocking LOS. The site already has power and fibre optic cable running to it so ideally I would've liked to be able to sent the packets over the fibre and pipe them to the RX unit. I may try this site with LoRa one day.

Hi uncle_bob, of course I remember.
Great part of the fun on all of this, is trying new things and new possibilities (I completely understand the Engolling enthusiasm). Let me launch a challenge to you: why not start to try using something like a TTL to TCP/IP adapter, for that specific situation. Comunication is only in one direction, so you only need to connect the Data Out pin of the transmitter interface to the TX pin of the adapter, and do the reverse operation at the reception point, RX pin to Data In of the WeatherDuino receiver. It may work, the fun is trying.

[Image: s-l1600.jpg]

Search on eBay for:
Ethernet to TTL RS232 Serial TTL to TCP/ IP RJ45 Convert Transmission Module

Reply
#7

Werk, You've given me an idea!
I have a few serial to IP servers that we used to use before our RS232/RS485 devices had TCP/IP. I wonder if they might work.

They look like this:
[Image: images?q=tbn:ANd9GcThHHneG5V2yMp3BM9ixY6...XKaQFUBjW7]
From the manual: https://www.lantronix.com/wp-content/upl...100_UG.pdf

Application Examples
Using a method called serial tunneling, the UDS encapsulates serial data into
packets and transports them over Ethernet. Using two UDS units, connected by a
network, virtual serial connections can extend across a facility or around the world.


Protocol Support
The UDS uses the Internet Protocol (IP) for network communications and the
Transmission Control Protocol (TCP) to assure that no data is lost or duplicated and
everything sent to the connection arrives correctly at the target.
Supported protocols include:
‹
ARP, UDP, TCP, ICMP, Telnet, TFTP, AutoIP, DHCP, HTTP, and SNMP for network communications.
‹
TCP, UDP, and Telnet for connections to the serial port.
‹
TFTP for firmware updates.
‹
IP for addressing, routing, and data block handling over the network.
‹
User Datagram Protocol (UDP) for typical datagram applications in which devices interact with other devices
without a point-to-point connection.


Looks like the dining table might be an experimentation table this weekend Smile
I could always just buy those ones on ebay, but I'm poor and are a bugger for a challenge haha.
Reply
#8

Hi Werk and uncle_bob, thank you for your feedback.

Since I have the GSM module here, I will in any case try to connect it to an TX module and check if the Nano has enough memory to handle this task. So I will provide some code solution and then you can decide if you integrate it or not.
But be aware, since I am more into hardware than software my code will look exactly like that. I know what I want to do and what the hardware is able to but my language is like from a three year old child  Rolleyes .

The same with the SD Card, I will try and integrate it in your TX Module Code and than you can decide.

All my ideas originate from the things I already missed from my self made station. 

Regards,
engolling
Reply
#9

(01-03-2018, 07:12)uncle_bob Wrote:  Looks like the dining table might be an experimentation table this weekend Smile
I could always just buy those ones on ebay, but I'm poor and are a bugger for a challenge haha.

Be carefull uncle_bob, RS232 voltage levels are quite diferrent from TTL voltage levels, to use your RS232/RS485 device, you need to use an RS232 to TTL converter like MAX232, or you will kill your Nano (Mega, etc)
http://www.ti.com/lit/ds/symlink/max232.pdf

The chinese device seems to be ready to work with TTL levels

Reply
#10

Hello,

concerning the TX module with GSM, it is still on my todo list to try it some time - but there are much more points above on my list... the days should have 36h  Confused   Wink .

Since I'm working more with the WeatherDuino and trying out different TX modules I miss a feature of tracing all the data. My idea would be to use one of the UARTs of the Mega2560 (e.g. UART2) to send all stored data of the RX Module, TX Modules, AQM to a tracer each minute.

To make it fast and memory saving but easy my idea would be to to send a fixed layout in hex values separated by semicolon, each minute a new row. To parse it, you can just write a simple parser in python

The data_structs.h gives a good overview of the data sent by TX modules and AQM, but I did not find the variables where the data of the RX module like temp, humidity and pressure or the recent timestamp is stored by getting over it quickly.
I will try to make a suggestion for the extra tracing interface the next days.

Regards,
engolling
Reply




Users browsing this thread: 3 Guest(s)