Recommended Radio/Dongle?

[Cyrus]

Hello!, 

I'm looking after a project that needs temperature monitoring of food baskets (50 to 100 per shipment) while on transit. They will be picked up at certain location, transported in a cold truck and delivered at several locations. 

I looked after the solution built at wirelesstag.net, the tags are super small, the  hub seems sturdy & the cloud service has a lot of features. Unluckily, it would be missing GPS location which I also need & I'm worried about the company disappearing and losing the whole solution (support feedback from the company seems scarse). Although, if GPS was supported I'm willing to give it a try as is.

On the other side, some people suggested me to look into RTL-SDR + sensors like this one: https://www.amazon.com/dp/B07R4GZXWX?ref_=cm_sw_r_apan_dp_XBCQ7BE7F0GWRJGX826S&th=1, which would require a full blown DIY solution (maybe with grafana & influxdb in the back).

If going with the DIY route, I can think of:

# Truck

- Dell Wyse 3040 running Linux

- Balena.IO for remote management

- Secondary 12v battery to power de DIY hub

- DC-DC battery charger (to charge the secondary battery with the main one in the truck)

- LTE dongle or LTE/WiFi router

- USB GPS antenna

- RTL-SDR dongle 

- Script collecting tag information (identifier, temperature, truck location)

- MQTT delivery to public server

# Server (would love to use a plug 'n' play solution if available)

- MQTT receiver

- InfluxDB for data collection

- Grafana

# Office (departure location)

Similar setup as the one in the truck, but running from AC source and not battery.

Given I would require to mount a relay/hub in a truck, I would like to request your recommendations for the SDR radio. I've seen that the inexpensive Realtek ones run hot and I'm worried about it dying in the middle of a delivery. In my country, 40°C is common outside.

Regards,

Cyrus.

[Christian Z.]

Interesting. For the receiver side I'd use a radio chip like the CC1101 (this will involve custom programming) and maybe a Raspi Zero W? (You could even get by with an ESP -- but that needs serious programming.)

Otherwise the Nooelec SDRSMArt have heatsinking using a metal housing.

Not so easy for the senders, they will step on each others toes, "channel" selectors won't help much, constant collisions with 100 sensors are a given.

Maybe get some kind of specialized "tag" like you mention and only program the recevier side?

[Benjamin Larsson]

Hi.

On 11/02/2023 18:41, Cyrus wrote:
> Hello!,
>
> I'm looking after a project that needs temperature monitoring of food
> baskets (50 to 100 per shipment) while on transit. They will be picked
> up at certain location, transported in a cold truck and delivered at
> several locations.
>
> I looked after the solution built at wirelesstag.net, the tags are super
> small, the  hub seems sturdy & the cloud service has a lot of features.
> Unluckily, it would be missing GPS location which I also need & I'm
> worried about the company disappearing and losing the whole solution
> (support feedback from the company seems scarse). Although, if GPS was
> supported I'm willing to give it a try as is.

Interesting project. I'll bite.

>
> On the other side, some people suggested me to look into RTL-SDR +
> sensors like this
> one: https://www.amazon.com/dp/B07R4GZXWX?ref_=cm_sw_r_apan_dp_XBCQ7BE7F0GWRJGX826S&th=1, which would require a full blown DIY solution (maybe with grafana & influxdb in the back).

I interpret this as a need of 50-100 sensors with 1 in each basket. If
that is the case you will end up with an addressing problem if you chose
the above sensor. You will have a really hard time matching sensors and
received values as you only have 3 channels that you can control.

I don't know the accuracy requirement but I would go with this type of
sensor instead:

https://www.amazon.com/Monitoring-Installed-Windowshield-Real-time-Temperature/dp/B08LK3MDC3/ref=sr_1_3?crid=DFLKZ6DGD6OT&keywords=tpms&qid=1676142702&sprefix=tpms%2Caps%2C200&sr=8-3

It only has a single digit temperature reading and I don't know how
accurate the reading is but what these sensors usually have is a 24-bit
large id range. In theory you should be able to calibrate each device
around the temperature you are interested in. Then you can fixup the
readings in the processing back-end. These sensors usually transmit for
only a short duration so there would be less signal overlap when there
are many at one place.

One more issue with this sensor is that there are several manufacturers
and we haven't figured out the protocol for some of them. But that
should be possible to solve with proper sourcing.

If you go with the non rt_433 route there are versions of this type of
sensor that uses Bluetooth. That might be a better fit.

>
> Given I would require to mount a relay/hub in a truck, I would like to
> request your recommendations for the SDR radio. I've seen that the
> inexpensive Realtek ones run hot and I'm worried about it dying in the
> middle of a delivery. In my country, 40°C is common outside.
>
> Regards,
> Cyrus.
>

Regarding recommendation for a rtl-sdr device any with a proper metal
casing and r820t2 tuner should work fine.

MvH
Benjamin Larsson

[Cyrus]

Hello!

El sáb, 11 de feb. de 2023 16:52, Christian Z. <chri...@zuckschwerdt.org> escribió:

Interesting. For the receiver side I'd use a radio chip like the CC1101 (this will involve custom programming) and maybe a Raspi Zero W? (You could even get by with an ESP -- but that needs serious programming.)

Otherwise the Nooelec SDRSMArt have heatsinking using a metal housing.

I understand the Noolec option has higher level programing interface. I can't spend too much time going super low level on this. For the brains, I already have a couple of Wyse 3040 thin clients that run Atom and can be powered with 12v.

Not so easy for the senders, they will step on each others toes, "channel" selectors won't help much, constant collisions with 100 sensors are a given.

Maybe get some kind of specialized "tag" like you mention and only program the recevier side?

So, maybe these RF sensors are not the right tool for the task. I've been looking for BLE alternatives, but I'm failing to find cost effective & tiny footprint options.

Regards,

Cyrus.

[Cyrus]

El sáb, 11 de feb. de 2023 17:06, 'Benjamin Larsson' via rtl_433 <rtl...@googlegroups.com> escribió:

Hi.

On 11/02/2023 18:41, Cyrus wrote:
> Hello!,
>
> I'm looking after a project that needs temperature monitoring of food
> baskets (50 to 100 per shipment) while on transit. They will be picked
> up at certain location, transported in a cold truck and delivered at
> several locations.
>
> I looked after the solution built at wirelesstag.net, the tags are super
> small, the  hub seems sturdy & the cloud service has a lot of features.
> Unluckily, it would be missing GPS location which I also need & I'm
> worried about the company disappearing and losing the whole solution
> (support feedback from the company seems scarse). Although, if GPS was
> supported I'm willing to give it a try as is.

Interesting project. I'll bite.

Please report back :)

>
> On the other side, some people suggested me to look into RTL-SDR +
> sensors like this
> one: https://www.amazon.com/dp/B07R4GZXWX?ref_=cm_sw_r_apan_dp_XBCQ7BE7F0GWRJGX826S&th=1, which would require a full blown DIY solution (maybe with grafana & influxdb in the back).

I interpret this as a need of 50-100 sensors with 1 in each basket. If

Correct interpretation. Later might be nice to include fridge sensors (one per cooling room/fridge), but starting point is for monitored basket.

that is the case you will end up with an addressing problem if you chose
the above sensor. You will have a really hard time matching sensors and
received values as you only have 3 channels that you can control.

So, it's a "no go". I'm glad to find that early in the project, will have to look for other solutions.

I don't know the accuracy requirement but I would go with this type of
sensor instead:

https://www.amazon.com/Monitoring-Installed-Windowshield-Real-time-Temperature/dp/B08LK3MDC3/ref=sr_1_3?crid=DFLKZ6DGD6OT&keywords=tpms&qid=1676142702&sprefix=tpms%2Caps%2C200&sr=8-3

It only has a single digit temperature reading

What do you mean by single digit?. In the image I see a "29" reading.

What would be required for it to reach  "100 sensors concurrency"?. The original option I found also handles buffering which allows to send a long history of measures. Not sure how it tracks time stamps though.

and I don't know how
accurate the reading is but what these sensors usually have is a 24-bit
large id range. In theory you should be able to calibrate each device
around the temperature you are interested in. Then you can fixup the
readings in the processing back-end. These sensors usually transmit for
only a short duration so there would be less signal overlap when there
are many at one place.

One more issue with this sensor is that there are several manufacturers
and we haven't figured out the protocol for some of them. But that
should be possible to solve with proper sourcing.

Any reference to options with known protocol you can point me to?.

If you go with the non rt_433 route there are versions of this type of
sensor that uses Bluetooth. That might be a better fit.

I've failed to find a cost effective option with small enough sensors. Found mixed reviews for BLE.

Also looked at z-wave options (bad experiences everywhere), LoRaWAN (no small or cost effective devices either)

Also found very good comments regarding rt_433 and wirelesstag.net. My understanding so far is that in both cases concurrency is a show stopper (the wirelesstag.net hub can only serve 20 tags).

>
> Given I would require to mount a relay/hub in a truck, I would like to
> request your recommendations for the SDR radio. I've seen that the
> inexpensive Realtek ones run hot and I'm worried about it dying in the
> middle of a delivery. In my country, 40°C is common outside.
>
> Regards,
> Cyrus.
>
Regarding recommendation for a rtl-sdr device any with a proper metal
casing and r820t2 tuner should work fine.

I've looked so far after LimeSDR (cost prohibitive) and Nooelec (mentioned here in this thread).

MvH
Benjamin Larsson

--

Regards,

Cyrus.

[Benjamin Larsson]

On 11/02/2023 21:47, Cyrus wrote:
>
>
>
> I don't know the accuracy requirement but I would go with this type of
> sensor instead:
>

> https://www.amazon.com/Monitoring-Installed-Windowshield-Real-time-Temperature/dp/B08LK3MDC3/ref=sr_1_3?crid=DFLKZ6DGD6OT&keywords=tpms&qid=1676142702&sprefix=tpms%2Caps%2C200&sr=8-3 <https://www.amazon.com/Monitoring-Installed-Windowshield-Real-time-Temperature/dp/B08LK3MDC3/ref=sr_1_3?crid=DFLKZ6DGD6OT&keywords=tpms&qid=1676142702&sprefix=tpms%2Caps%2C200&sr=8-3>

>
> It only has a single digit temperature reading
>
>
> What do you mean by single digit?. In the image I see a "29" reading.

I mean no decimal digits. What precision is needed. Is +-2 degrees fine?
Then this type of sensor would be suitable.

>
> What would be required for it to reach  "100 sensors concurrency"?. The
> original option I found also handles buffering which allows to send a
> long history of measures. Not sure how it tracks time stamps though.

Most sensors only transmit the current readings at a periodic interval.
Time stamping must be handled on the receiving end. For 100 sensors to
work at the same time in cramped space the sensors need to have logic to
make sure that enough values are getting through to the receiver.

There is another class of sensors that actually sends historic readings.
The wmbus class of sensors have support for lots of things. There are
models that might be suitable.

>
> One more issue with this sensor is that there are several manufacturers
> and we haven't figured out the protocol for some of them. But that
> should be possible to solve with proper sourcing.
>
>
> Any reference to options with known protocol you can point me to?.
>

Not really because the Chinese suppliers switch sources when something
cheaper appears. The only way is to buy and test if it is something that
can be made to work.

>
> If you go with the non rt_433 route there are versions of this type of
> sensor that uses Bluetooth. That might be a better fit.
>
>
> I've failed to find a cost effective option with small enough sensors.
> Found mixed reviews for BLE.

Search for "tpms ble" on all available online markets.

>
> Also looked at z-wave options (bad experiences everywhere), LoRaWAN (no
> small or cost effective devices either)
>
> Also found very good comments regarding rt_433 and wirelesstag.net

> <http://wirelesstag.net>. My understanding so far is that in both cases

> concurrency is a show stopper (the wirelesstag.net

> <http://wirelesstag.net> hub can only serve 20 tags).
>

I would really go for a tpms type of sensor. It is small, sane protocol,
24 bit id, rugged and versatile. It even has a screw-fitting that could
be reused.

> > Given I would require to mount a relay/hub in a truck, I would
> like to
> > request your recommendations for the SDR radio. I've seen that the
> > inexpensive Realtek ones run hot and I'm worried about it dying
> in the
> > middle of a delivery. In my country, 40°C is common outside.
> >
> > Regards,
> > Cyrus.
> >
> Regarding recommendation for a rtl-sdr device any with a proper metal
> casing and r820t2 tuner should work fine.

Dont complicate things. Go to a random online markets and search for
rtl-sdr (in metal casing and with a r820t2 tuner) and pick something
that looks ok.

Anyway I would try to fit the project into the limits of the tpms
sensors (BLE or simple rf ones). I can find 100x units for ca $500 on
Aliexpress. This is as cost effective as it can get.

I would just start ordering devices that could form a solution and test
them. Your main issue is to be able to scale technically and
economically. The right tpms sensor should be able to deliver that.

MvH
Benjamin Larsson

[Cyrus]

El sáb, 11 de feb. de 2023 18:50, 'Benjamin Larsson' via rtl_433 <rtl...@googlegroups.com> escribió:

On 11/02/2023 21:47, Cyrus wrote:

.

>
> What would be required for it to reach  "100 sensors concurrency"?. The
> original option I found also handles buffering which allows to send a
> long history of measures. Not sure how it tracks time stamps though.

Most sensors only transmit the current readings at a periodic interval.
Time stamping must be handled on the receiving end. For 100 sensors to
work at the same time in cramped space the sensors need to have logic to
make sure that enough values are getting through to the receiver.

There is another class of sensors that actually sends historic readings.
The wmbus class of sensors have support for lots of things. There are
models that might be suitable.

Should I be able to find TPMS & WMBUS options?, Or wMBUS is a different route?.

Buffering of historic data would be valuable to accommodate connection issues or faraday cage scenarios (sensor in the refrigerated load compartment & hub in the driver's cockpit).

Regards,

Cyrus.

[Christian Z.]

The TPMS sensors are nice and useable. But note that the send interval might be huge (every hour maybe?) or they might not transmit without pressure at all.

The wirelesstag.net talk about "sub-GHz frequency" -- that's 868M or 433.92M. rtl_433 might be an option for those. And you could likely scale the "20 units max" somewhat, e.g. I have 3-channel sensors and I use 6 with not problems.

But they are pricey and won't be feature-complete with rtl_433.

[Benjamin Larsson]

On 11/02/2023 23:04, Cyrus wrote:
>
> There is another class of sensors that actually sends historic
> readings.
> The wmbus class of sensors have support for lots of things. There are
> models that might be suitable.
>
>
> Should I be able to find TPMS & WMBUS options?, Or wMBUS is a different
> route?.
>
> Buffering of historic data would be valuable to accommodate connection
> issues or faraday cage scenarios (sensor in the refrigerated load
> compartment & hub in the driver's cockpit).
>
> Regards,
> Cyrus.

There is a complexity cost in everything. wmbus sensors are around $50
per unit, when you talk about using 100+ sensors that results in quite a
steep cost.

But why do you need that many sensors? Isn't one in the delivery van enough?

MvH
Benjamin Larsson

[Benjamin Larsson]

On 11/02/2023 23:10, Christian Z. wrote:
> The TPMS sensors are nice and useable. But note that the send interval
> might be huge (every hour maybe?) or they might not transmit without
> pressure at all.
>

Yeah, I forgot about that. So if you choose to build with tpms you need
to also set the tpms to transmit periodically.

MvH
Benjamin Larsson

[Cyrus]

The challenge, as always, is not technical :)

Our biggest client is running some temperature checks once we unload. The issue is that they leave the baskets without refrigeration on the floor for 20 min & take the measurement after than because they're "busy".

The company heads complain about cool chain being broken on our side, the soldiers (last man in the company) are unable or unwilling to change procedure of unloading and documenting the temperature on their side.

I need to document the cold chain of a given shipment, even after we unload from the truck.

Regards,

Cyrus 

[Cyrus]

Do you use the stock/included console for that?

[talk2gregory]

I just posted some test signals yesterday for an aftermarket TPMS system for help with decoding on the rtl_433 github. These sensors broadcast a message every 5 minutes under pressure. Its called EEZ Tire RV model 618E. It uses screw on sensors that fit a typical valve stem.

Sent from my Galaxy

--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/CAEaLa5EQnX%2BvwHtThmbmujCk1gwkoo6RPxj_fjam9UoD9569tg%40mail.gmail.com.

[David Powell]

It sounds like you don't need any RF stuff at all, what you need is an inexpensive data logger.  You could make them for maybe $3 each with a simple ESP8266 and a temperature sensor.  Stick one in each basket at the start of the shipping, and then download the data from them at the end. Since the ESP8266 has built-in wifi, you could even download the data wirelessly at any time with just a phone or laptop.

David

[Cyrus]

El sáb., 11 de febrero de 2023 22:35, David Powell <da...@depowell.com> escribió:

It sounds like you don't need any RF stuff at all, what you need is an inexpensive data logger.  You could make them for maybe $3 each with a simple ESP8266 and a temperature sensor.  Stick one in each basket at the start of the shipping, and then download the data from them at the end. Since the ESP8266 has built-in wifi, you could even download the data wirelessly at any time with just a phone or laptop.

David

Hello David, 

I really like the TPMS option for its sturdiness and size. Also I understand if buffering or any other intelligence is needed something like what you propose is better.

Probable an ESP32 with BLE is better for connectivity (I know, probably more expensive). We sometimes leave some baskets in the clients warehouse and would.like.to get the measurements from a machine in the truck without having to reach the basket and without human intervention.

Regards,

Cyrus.

On 2/11/23 7:20 PM, Cyrus wrote:

El sáb, 11 de feb. de 2023 19:55, Benjamin Larsson <ba...@ludd.ltu.se> escribió:

On 11/02/2023 23:04, Cyrus wrote:

There is a complexity cost in everything. wmbus sensors are around $50
per unit, when you talk about using 100+ sensors that results in quite a
steep cost.

But why do you need that many sensors? Isn't one in the delivery van enough?

MvH
Benjamin Larsson

The challenge, as always, is not technical :)

Our biggest client is running some temperature checks once we unload. The issue is that they leave the baskets without refrigeration on the floor for 20 min & take the measurement after than because they're "busy".

The company heads complain about cool chain being broken on our side, the soldiers (last man in the company) are unable or unwilling to change procedure of unloading and documenting the temperature on their side.

I need to document the cold chain of a given shipment, even after we unload from the truck.

Regards,

Cyrus 

--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/CAEaLa5EQnX%2BvwHtThmbmujCk1gwkoo6RPxj_fjam9UoD9569tg%40mail.gmail.com.

--

You received this message because you are subscribed to a topic in the Google Groups "rtl_433" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtl_433/ds2FC-DvgnA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rtl_433+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/456089f8-5786-b13c-3d92-b93dbe78f198%40depowell.com.

[Christian Z.]

We sometimes leave some baskets in the clients warehouse and would.like.to get the measurements from a machine in the truck without having to reach the basket and without human intervention.

The machine/truck would need to sit for an hour or more to collect data. TPMS that are not in rotation don't send often. Also without pressure TPMS might go into hibernation.

The "warming up for 20 minutes" scenario is not a strength of a sensor that reads data every hour.

It would be a great solution if we could figure out how to programm the "universal" TPMS. But universal TPMS are the same price as the wireless tags you found.