(I'm new to this NG)
the budget not being crucial,
what raspberry pi "version" (I mean main model and/or
submodels/subversions) would you choose to perform these tasks
(I'm new to this NG)
the budget not being crucial,
what raspberry pi "version" (I mean main model and/or
submodels/subversions) would you choose to perform these tasks
1) read a dozen of temperature detectors (the model of them
have not been determined, maybe some RTD PT100 and some
thermistors, or even some NTC), connected by an "unlimited"
number of 0,22 mm2 copper wires. The detectors will span in
a 1-40 m distances (*)
2) operate by means of some ralays
2-a] two electrovalves 220 V normally closed
2-b) one circulation pump 220 V
3) log data on a ext4 usb key
4) allow to connect some display (either touch or plain,
with the need of a keyboard)
5) optionally either ethernet or wireless support would be
appreciated for system update. This point has not been
properly considered yet. Maybe for an "IoT" system, a
crystallized system could be preferable
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
The Raspberry "brain" should manage a multi heat-source solar-biomass
water warming system, with forced circulation
Soviet_Mario <SovietMario@cccp.mir> wrote:
3) log data on a ext4 usb key
They've all got USB so that's easy.
Soviet_Mario <SovietMario@cccp.mir> wrote:
(I'm new to this NG)
the budget not being crucial,
what raspberry pi "version" (I mean main model and/or
submodels/subversions) would you choose to perform these tasks
1) read a dozen of temperature detectors (the model of them
have not been determined, maybe some RTD PT100 and some
thermistors, or even some NTC), connected by an "unlimited"
number of 0,22 mm2 copper wires. The detectors will span in
a 1-40 m distances (*)
The Pi Pico is the only one with a built-in ADC. But even it
only has three inputs, so you'll either need to use analogue
switch circuitry or an external ADC.
If you use an external ADC you could connect that to any Pi
model. You might also consider mounting individual ADCs
remotely at each sensor and communicating with them digitally,
to avoid electrical noise picked up by the long wires messing
up the readings.
2) operate by means of some ralays
2-a] two electrovalves 220 V normally closed
2-b) one circulation pump 220 V
The 300mA output current of the Pi Pico could drive many models
of relay directly (with protection diodes). Equally other models
could switch them via a transistor without much more complexity.
3) log data on a ext4 usb key
They've all got USB so that's easy.
4) allow to connect some display (either touch or plain,
with the need of a keyboard)
You probably want one with HDMI output then, which rules out the
Pico. Though perhaps you mean small displays which could be run
from the GPIO.
5) optionally either ethernet or wireless support would be
appreciated for system update. This point has not been
properly considered yet. Maybe for an "IoT" system, a
crystallized system could be preferable
Also rules out the Pico.
Overall I'd say that a Pi Zero W would do all you need, so long
as you're willing to use an external ADC chip and buffer
transistors for the relays. You'll need some external circuitry
whatever you choose. Equally most other "big" Pi models suit,
and more USB ports may avoid needing to use a hub if you choose
to connect a keyboard.
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
Sounds very fancy.
Note that I wouldn't trust the Pis to be super
reliable, eg. compared to boards designed for industrial
environments.
On 03/09/2021 07:59, Soviet_Mario wrote:
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
You don't need more than a Pi zero W to make this useless
idea even worse ;-)
Den 2021-09-03 kl. 08:59, skrev Soviet_Mario:
(I'm new to this NG)
the budget not being crucial,
what raspberry pi "version" (I mean main model and/or
submodels/subversions) would you choose to perform these
tasks
I'd use a 3b+ because
* rpi display fit it well <https://www.raspberrypi.org/products/raspberry-pi-touch-display/>
* has wifi and ubs-ports (no need for a usb-hub that the
zero would need)
* easily boots from SSD via usb. No worry about wearing down
the SD card
i use a 120 Gb version of this since 3 years <https://www.amazon.com/TC-SUNBOW-120GB-Portable-External/dp/B07H81XFK9/ref=sr_1_5?dchild=1&keywords=tc%2Bsunbow&qid=1630655923&sr=8-5&th=1>
The pi holds a postgres DB with quite some read/writes and
also - lots of file logging
A Zero may have enough umpf for your needs, but connectivity is
harder
"unlimited" number of sensors
- how do you plan that? OnWire?
Some relays do not work with PI directly - some do.
I've got some chinese realys both in singel and double
configuration on a board.
The singel ones do not work with a Pi - the double one do.
Both work with an Arduino Nano - so - external circuit may
be needed
Il 03/09/21 10:03, Björn Lundin ha scritto:
Den 2021-09-03 kl. 08:59, skrev Soviet_Mario:
(I'm new to this NG)
the budget not being crucial,
what raspberry pi "version" (I mean main model and/or
submodels/subversions) would you choose to perform these
tasks
I'd use a 3b+ because
* rpi display fit it well
<https://www.raspberrypi.org/products/raspberry-pi-touch-display/>
* has wifi and ubs-ports (no need for a usb-hub that the
zero would need)
* easily boots from SSD via usb. No worry about wearing
down the SD card
i use a 120 Gb version of this since 3 years
<https://www.amazon.com/TC-SUNBOW-120GB-Portable-External/dp/B07H81XFK9/ref=sr_1_5?dchild=1&keywords=tc%2Bsunbow&qid=1630655923&sr=8-5&th=1>
The pi holds a postgres DB with quite some read/writes and
also - lots of file logging
A Zero may have enough umpf for your needs, but
connectivity is
harder
"unlimited" number of sensors
no, well, I wrote "unlimited" number of wires/cables, as I
have drawn two independent 8x0,22 mm2 poles cables plus a
3x2,5 mm2 poles cable for power.
So I was thinking wiring would never become a bottleneck
whatever solution will be chosen.
The thermal sensors will roughly a dozen or slightly less
(the critical issue will be the long distance of 3 of them
from the "brain", 25 to 40 meters away).
- how do you plan that? OnWire?
I still have to study much of the terms, sorry :(
Some relays do not work with PI directly - some do.
I'll have to choose suitable ones then, and at that time
I'll be here again to ask :D
I've got some chinese realys both in singel and double
configuration on a board.
The singel ones do not work with a Pi - the double one do.
Both work with an Arduino Nano - so - external circuit may
be needed
I'll have to strieve for long, but that was being expected :\
TY
(I'm new to this NG)
the budget not being crucial,
what raspberry pi "version" (I mean main model and/or
submodels/subversions) would you choose to perform these tasks
1) read a dozen of temperature detectors (the model of them
have not been determined, maybe some RTD PT100 and some
thermistors, or even some NTC), connected by an "unlimited"
number of 0,22 mm2 copper wires. The detectors will span in
a 1-40 m distances (*)
2) operate by means of some ralays
2-a] two electrovalves 220 V normally closed
2-b) one circulation pump 220 V
3) log data on a ext4 usb key
4) allow to connect some display (either touch or plain,
with the need of a keyboard)
5) optionally either ethernet or wireless support would be
appreciated for system update. This point has not been
properly considered yet. Maybe for an "IoT" system, a
crystallized system could be preferable
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
tnx in advance for any help
Il 03/09/21 09:42, Computer Nerd Kev ha scritto:
Soviet_Mario <SovietMario@cccp.mir> wrote:
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
Sounds very fancy.
I might possibly ask further clarifications for the parts
above, but preliminarly ... could you explain why it is fancy ?
Note that I wouldn't trust the Pis to be super
reliable, eg. compared to boards designed for industrial
environments.
feel completely free to suggest any other platform which,
with REASONABLE amount of expansion/integrations, would be
able to comply with the points I have specified.
As for the fancy choice, I am a complete novice in IoT, and
as a Debian user, I felt confident with raspbian and
development SW tools
but I'm open to *ANY* other suggestions as well, of which I
thank you in advance
(I'm new to this NG)
the budget not being crucial,
what raspberry pi "version" (I mean main model and/or
submodels/subversions) would you choose to perform these tasks
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
Il 03/09/21 10:09, The Natural Philosopher ha scritto:
On 03/09/2021 07:59, Soviet_Mario wrote:
The Raspberry "brain" should manage a multi heat-source solar-biomass
water warming system, with forced circulation
You don't need more than a Pi zero W to make this useless idea even
worse ;-)
I'm not familiar with this NG so I can't assume to be able to recognize trolling, but ... this seems that.
I am not asking if the general idea is good or not, just what would be a
good central system choice to control all the devices.
Sb maybe deprecated the choice of the raspberry per se, and I hope to discover more about the point
Soviet_Mario <SovietMario@cccp.mir> wrote:
Il 03/09/21 09:42, Computer Nerd Kev ha scritto:
Soviet_Mario <SovietMario@cccp.mir> wrote:
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
Sounds very fancy.
I might possibly ask further clarifications for the parts
above, but preliminarly ... could you explain why it is fancy ?
"Fancy" is just my response to "multi heat-source solar-biomass
water warming system" when I actually haven't got the first clue
what that means.
In terms of electronics, the demands that you've
specified seem modest enough.
Note that I wouldn't trust the Pis to be super
reliable, eg. compared to boards designed for industrial
environments.
feel completely free to suggest any other platform which,
with REASONABLE amount of expansion/integrations, would be
able to comply with the points I have specified.
As for the fancy choice, I am a complete novice in IoT, and
as a Debian user, I felt confident with raspbian and
development SW tools
but I'm open to *ANY* other suggestions as well, of which I
thank you in advance
The Pis are one range amongst many Single Board Computer (SBC)
ranges. I'm not an expert on them, and I mainly look at lists on
this site as a starting point: https://linuxgizmos.com/150-open-spec-community-backed-linux-sbcs-under-200/
Try looking for the word "industrial" on that page for the sort
of board that might be a bit above the Pis in terms of reliability.
It'll generally be easier to develop software for the Pis than for
some obscure industrial-spec SBC though.
On 03/09/2021 10:52, Soviet_Mario wrote:
Il 03/09/21 10:09, The Natural Philosopher ha scritto:
On 03/09/2021 07:59, Soviet_Mario wrote:
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
You don't need more than a Pi zero W to make this useless
idea even worse ;-)
I'm not familiar with this NG so I can't assume to be able
to recognize trolling, but ... this seems that.
I am not asking if the general idea is good or not, just
what would be a good central system choice to control all
the devices.
Sb maybe deprecated the choice of the raspberry per se,
and I hope to discover more about the point
Pi zero has a decent operating system and the WiFi has
adequate hifi and usb support for disk, I/O is the weakness
compared to Arduino.
But it does support I2C bus and many temp sensors do the same.
My point stands. Pi Zero W will do what you want, sadly the
multi heat-source solar-biomass water warming system, with
forced circulation probably will not.
Experience suggest it will save no money
and will certainly
not save the planet.
OTOH if you are selling
such systems to gullible greentards,
it will probably make a profit
On 03/09/2021 07:59, Soviet_Mario wrote:
(I'm new to this NG)
the budget not being crucial,
what raspberry pi "version" (I mean main model and/or
submodels/subversions) would you choose to perform these
tasks
1) read a dozen of temperature detectors (the model of them
have not been determined, maybe some RTD PT100 and some
thermistors, or even some NTC), connected by an "unlimited"
number of 0,22 mm2 copper wires. The detectors will span in
a 1-40 m distances (*)
2) operate by means of some ralays
2-a] two electrovalves 220 V normally closed
2-b) one circulation pump 220 V
3) log data on a ext4 usb key
4) allow to connect some display (either touch or plain,
with the need of a keyboard)
5) optionally either ethernet or wireless support would be
appreciated for system update. This point has not been
properly considered yet. Maybe for an "IoT" system, a
crystallized system could be preferable
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
tnx in advance for any help
Programming?
Suggest Raspberry Pi 3B+
Soviet_Mario <SovietMario@cccp.mir> wrote:
(I'm new to this NG)
the budget not being crucial,
what raspberry pi "version" (I mean main model and/or
submodels/subversions) would you choose to perform these tasks
I'd think about splitting this up into two parts:
Part 1 does the temperature monitoring and any control loops. For example 'if too hot then open relay #4'
Part 2 does the display, logging, networking, etc. It just reads the status and sets parameters of Part 1.
The reason for splitting this up is it's safer if Part 2 crashes, your house doesn't melt by jamming the furnace on. Maybe you can't adjust your temperature up or down but at least it stays running.
Any Pi with wifi would be fine for Part 2. Part 1 would be a
microcontroller of some kind - for example a Pi Pico, an Arduino, an ESP32
or whatever board you feel like. Pick something with a nice software dev enviornment and suitable I/Os.
A more involved design might have Part 1 cache recent recordings, so if Part 2 crashes it can re-fetch the last hour/day/week of recordings without a
gap.
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
I would have a look at Home Assistant on the Pi and ESPHome on an ESP32 or ESP8266 microcontroller, as that probably does most of what you want
already.
You mostly just need to build the controls using JSON or a clicky
GUI, it does most of the rest for you. HA and ESPHome are part of the same organisation so they are well integrated together.
They may well have
integrations with your existing kit (eg if it speaks Modbus or has a cloud interface).
HA is not the most lightweight thing ever so benefits from having a Pi 4, although the cheapest Pi 4 is fine.
Theo
1) read a dozen of temperature detectors (the model of them
have not been determined, maybe some RTD PT100 and some
thermistors, or even some NTC), connected by an "unlimited"
number of 0,22 mm2 copper wires. The detectors will span in
a 1-40 m distances (*)
2) operate by means of some ralays
2-a] two electrovalves 220 V normally closed
2-b) one circulation pump 220 V
3) log data on a ext4 usb key
4) allow to connect some display (either touch or plain,
with the need of a keyboard)
5) optionally either ethernet or wireless support would be
appreciated for system update. This point has not been
properly considered yet. Maybe for an "IoT" system, a
crystallized system could be preferable
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
The "brain" must check the various temperatures (the
storage, and the sources), do some evaluations, and decide
whether or not to activate the PUMP, and which, if any,
valve to open, to put the selected source/s online, and
recharge the buffer.
Then do some log (how many times the pump was activeted and
for how long, the detected temperatures, the flowmeter data).
I'll have a look.
I must ad I have long be considering ESP32, but the SW
environment is unfamiliar to me, and I dunno if it can pilot
any kind of display to make mainteinance
you got perfectly the point ! In Debian i feel at home, but
I am completely unfamiliar with ESP32 or Arduino :\
I feel comfortable with C, C++ or Gambas, but I'll need to
find libraries to manage I/O on the ports, that's sure.
the calcite (CaCO3) would foul the coils, if the T soars often.
Personally, I'd use a Raspberry Pi3 combined with an Arduno nano.
The nano has 8 x 10bit A/D converters and 13 no-fuss digital I/O. It also accepts 5V inputs (and they are better protected).
This can do all your basic capture and clean-ups.
You can then pass this on to the Pi (i2c) maybe, or even simple serial.
The Pi can then to all the complex stuff, and manage touch screen I/O etc.
Both can be directly powered from a 5V supply.
1) read a dozen of temperature detectors (the model of them
have not been determined, maybe some RTD PT100 and some
thermistors, or even some NTC), connected by an "unlimited"
number of 0,22 mm2 copper wires. The detectors will span in
a 1-40 m distances (*)
On 03/09/2021 14:23, Soviet_Mario wrote:
the calcite (CaCO3) would foul the coils, if the T soars
often.
I can assure you that even cold water will deposit this.
You really need a water softener.
On Fri, 3 Sep 2021 15:02:22 +0200, Soviet_Mario <SovietMario@CCCP.MIR> declaimed the following:
The "brain" must check the various temperatures (theTake into account that the R-Pi does not have a battery-backed clock. Without a network connection allowing for time-synchronization, your logged time-stamps could be off; especially following a reboot (when the OS relies upon some value periodically written to a file).
storage, and the sources), do some evaluations, and decide
whether or not to activate the PUMP, and which, if any,
valve to open, to put the selected source/s online, and
recharge the buffer.
Then do some log (how many times the pump was activeted and
for how long, the detected temperatures, the flowmeter data).
I'll have a look.
I must ad I have long be considering ESP32, but the SW
environment is unfamiliar to me, and I dunno if it can pilot
any kind of display to make mainteinance
You'll need to consider the difference between a "microcomputer" (aka: embedded Linux system) running a full OS, and a "microcontroller" which, at best, may be running FreeRTOS built into your application.
Most all microcontrollers probably have a support library that can drive an Hitachi compatible 2x16 character LCD. Few will support a full keyboard. Parallax used to have an add-on board for their Propeller Quick-Start board with PS-2 ports for keyboard and mouse. Most do not have USB HOST ports (though you can find SD card add-ons for logging storage -- but they will only be using FAT filesystem). They have USB client ports
used to flash updates to the application.
"Maintenance" on a microcontroller typically consists of modifying/rebuilding the application on a desktop computer, then sending
the (re-)built application to the flash memory of the controller via USB. Think of a "smart" home thermostat. At most you have a few buttons which permit making changes to parameters stored in EEPROM [some boards have
EEPROM for parameter data as they don't allow write access to the flash].
Many also have on-board ADC (Arduino UNO and compatible has 6 ADC inputs, and up to 6 PWM outputs; TIVA C tm4c123g has two 12-bit ADC --
which appear to be MUXable among some 14 odd pins -- and way too many on-board timers [12, each which can be "split" into two half size timers]; Propeller... No ADC).
Note that there are two "classes" of microcontroller commonly available: the Uno and kin are Atmel AVR 8-bit processors; the
(discontinued) Arduino Due, Adafruit Metro Express, TIVA, STM are
variations of 32-bit ARM Cortex M-series processors [M0, M3, M4 and M4f {f
= floating point hardware} most common]. The Propeller is a custom design
-- 8 lock-step cores sharing all GPIO, no interrupts (one is supposed to assign a core to running polling loops to detect pin changes for
interrupts).
With microcontrollers you'll have to be concerned with on-board flash -- though most applications should fit, as the application runs from the flash memory -- it isn't like an embedded Linux board where the flash
memory is "disk", and the application(s) are loaded from "disk" to run in
the RAM. Microcontroller RAM is only for run-time variable data
(heap/stack).
TIVAs were cheap if one was in a country TI would ship to (the 123g model was around US$12 -- 80MHz Cortex M4f, 256kB flash, 32kB RAM; TM4C1294 was around $20 -- 120MHz M4f, 1MB flash, 256kB RAM, Ethernet [you need to include drivers in your application, so likely also need TI-RTOS]).
Arduino uses a form of C++ for the native language, though most users never see that level -- include a library, create an instance, and just use the object.
you got perfectly the point ! In Debian i feel at home, but
I am completely unfamiliar with ESP32 or Arduino :\
The Metro M4 Express native is CircuitPython, though one can load an Arduino compatible boot-loader and build Arduino style code. 120MHz M4f, 512kB flash, 192kB RAM, one ADC shared among 8 pins, one DAC shared among
two pins, 16 PWM https://learn.adafruit.com/adafruit-metro-m4-express-featuring-atsamd51
TIVA has a port of the Arduino IDE called Energia for simpler coding, but for complex stuff (TI-RTOS) uses Code Composer Studio.
Propeller... again, all custom -- SPIN, Propeller assembly, even a C compiler environment is available (SPIN is a byte-code interpreted
language; the applicable Propeller core [8 cores available] is loaded with the SPIN interpreter, and application code runs from the flash memory).
Everything else you've stated is what the microcontroller boards were optimized for. Low-power usage, no fragile file-system [power loss to a
Linux board can result in a trashed boot file-system -- Amateur Radio
Pi-Star systems actually run with the file system set to read-only, with
all dynamic data being stored in a RAM-disk -- which is lost on
power-fail], often have ADC and PWM on-board. Fast start-up since there is
no OS to load -- processor basically boots with the application in flash.
Your application probably doesn't need the fastest response times so slower
processor clocks [which contribute to low power usage] is fine. You should even be able to fit a PID logic system into a microcontroller [maybe look
for one running on M4f for the floating point math].
You'll still want a battery-backed RTC regardless of Linux or microcontroller board to time-stamp log entries, and probably an SD card
slot on which to do the logging.
tnx for this long and deep comparison. I'll try to go
through it again to fix some ideas
all correct. The fact I'd need some higher level logging
(also error states) is both debug, and mainteinance, and
later some statistics about the performance of the system.
I mean : I have burnt 60 kg of wood in 6 hours, the ini_T of
the buffer was XXX, the fin_T was YYY, So I have actually
stored, all included, ZZZ MJ in the buffer with external T =
2°C. This kind of diagnosis.
absolutely right, it has to do calm polling, few
calculations. But without a means of inquiring what is
happening I feel lost. I am not skilled working with
microcontrollers so as to understand sticking the nose
inside the voltages and so.
processor clocks [which contribute to low power usage] is fine. You should >> even be able to fit a PID logic system into a microcontroller [maybe look
for one running on M4f for the floating point math].
You'll still want a battery-backed RTC regardless of Linux or
microcontroller board to time-stamp log entries, and probably an SD card
slot on which to do the logging.
sure, a battery was taken into account. Also the pump and
the electrovalves would need uninterruptable power, so it is
a free meal :D
Whether a microcontroller or an embedded Linux board, the interfacing
with hardware is going to be similar. Embedded Linux is not "real-time",
but with relaxed polling periods that may not be significant. It's not
like you expect to react within 100ns to some interrupt condition.
I'll have a look.
I must ad I have long be considering ESP32, but the SW
environment is unfamiliar to me, and I dunno if it can pilot
any kind of display to make mainteinance
Try looking for the word "industrial" on that page for the sort
of board that might be a bit above the Pis in terms of reliability.
It'll generally be easier to develop software for the Pis than for
some obscure industrial-spec SBC though.
you got perfectly the point ! In Debian i feel at home, but
I am completely unfamiliar with ESP32 or Arduino :\
Il 03/09/21 14:04, Theo ha scritto:
sensible considerations. The wood-system is passively safe,
as it is not in pressure (an open air reservoire is
present), there is a floating valve self-replenish of the
tech. water in the source coils circuit, and a max.level
discharge system.
At worst the water will BOIL for a given time and vent
vapour from above, and the floating valve would detect water
loss and replenish from top with cold water.
It will not be good anyway, sure : the calcite (CaCO3) would
foul the coils, if the T soars often.
Any Pi with wifi would be fine for Part 2. Part 1 would be a microcontroller of some kind - for example a Pi Pico, an Arduino, an ESP32
I had thought of ESP32. The thing is : I am ignorant how to
communicate with Pi.
I would have a look at Home Assistant on the Pi and ESPHome on an ESP32 or ESP8266 microcontroller, as that probably does most of what you want already.
I'll do the search, but I haven't got very well the meaning.
The two projects are independent ?
On Fri, 3 Sep 2021 08:59:03 +0200, Soviet_Mario <SovietMario@CCCP.MIR> declaimed the following:
1) read a dozen of temperature detectors (the model of them
have not been determined, maybe some RTD PT100 and some
thermistors, or even some NTC), connected by an "unlimited"
number of 0,22 mm2 copper wires. The detectors will span in
a 1-40 m distances (*)
None of the R-Pi models I'm familiar with have usable Analog inputs, so any temperature sensor that reports via voltage change will require an external ADC board cf: https://learn.adafruit.com/reading-a-analog-in-and-controlling-audio-volume-with-the-raspberry-pi/connecting-the-cobbler-to-a-mcp3008
For sensors that use I2C or SPI -- you will have to determine how many sensors you need to address.
SPI will require a chip-select signal for each
device (but sharing the data in/out, and clock lines -- 3 lines plus 1 line per device; you may have to bit-bang the chip select; most SPI ports only natively control 1 or 2 chip selects). I2C will depend upon how many unique addresses can be configured on the devices, as the one I2C port will be limited to sending that many addresses; if devices have to share addresses, you will need another I2C bus for the duplicate addresses.
2) operate by means of some ralays
2-a] two electrovalves 220 V normally closed
2-b) one circulation pump 220 V
You'll likely need a relay driver board. The R-Pi digital signals are 3.3V and low-current; hitting them with a 5V signal, or attempting to transfer too much current, will kill the R-Pi. You'll definitely want some isolation from the 220V side
(I believe many of the relay boards are aimed
at robotics, being driven from one to four 12V batteries -- 12-48V DC, so
the relays may not be rated for 220V AC -- that may mean one set of "low voltage" relays are needed to drive the high voltage set.
3) log data on a ext4 usb key
Software and configuration... may want more than one USB port given the next...
4) allow to connect some display (either touch or plain,
with the need of a keyboard)
Most R-Pi's have HDMI ports for standard (modern) monitors and HD TVs.
Keyboard/mouse is probably best served using wireless models where one USB receiver works with both the keyboard and the mouse (Logitech "Unifying" receivers and peripherals are what I have experience with).
If you mean something like a 3-7 inch LCD display... Those may use a lot of the digital GPIO pins, reducing those available for the above
control system. Not to mention getting access to the pins when a display board is fitted over top...
5) optionally either ethernet or wireless support would be
appreciated for system update. This point has not been
properly considered yet. Maybe for an "IoT" system, a
crystallized system could be preferable
Every R-Pi that I know of has either or both Ethernet or WiFi (all current models have WiFi, the smaller ones may not have Ethernet ports).
The Raspberry "brain" should manage a multi heat-source
solar-biomass water warming system, with forced circulation
Software...
On Fri, 3 Sep 2021 08:59:03 +0200, Soviet_Mario <SovietMario@CCCP.MIR> declaimed the following:
1) read a dozen of temperature detectors (the model of them
have not been determined, maybe some RTD PT100 and some
thermistors, or even some NTC), connected by an "unlimited"
number of 0,22 mm2 copper wires. The detectors will span in
24AWG if my look-up is correct...
a 1-40 m distances (*)
... same look-up gives 76.4ohms/km... or just over 3ohm at 40m That is 3%
of the PT100 "100Ohm at 0degC" -- with two leads that comes to 6% which
needs to be compensated... Not that I'd want to run /any/ analog signal
that distance.
SPI is limited to 10m without using repeaters, so that counts out using SPI temperature sensors and/or SPI ADC -- so https://learn.adafruit.com/mcp3008-spi-adc is not an option...
I2C is limited to 10m at 10kBaud if using 22ga unshielded twisted pair (UTP) (phone or Ethernet cables). So those also are not an option for the long run cables.
Off hand -- you are likely going to have to install a microcontroller at the far end of those cable runs, so the sensors connect to the microcontroller with under 10m runs.
The microcontroller would then use a plain UART over UTP (real preference would be RS-422 differential vs RS-232 single-ended;
but that
means twice the wires, along with transceiver/receiver logic at each end; differential is more noise immune as +S and -S are sent over two cables, at the receiver the -S is "subtracted" (invert and add) to the +S. Line noise tends to be identical on both wires -- +S+1v, -S+1v -- when inverted and added, the noise cancels out.
You'll have to run a slow baud rate -- even RS-232 is only rated for 16m at 19.2kbps; longer runs are undefined.
40m is also going to be pushing it for WiFi (and definitely not going to be usable for BlueTooth).
Ethernet is rated for 100m -- but the code needed to run Ethernet on microcontrollers (if you find an Ethernet add-on) may hamper your
application size.
Often the microcontroller is configured as a simple
web-server, returning a page of, say, sensor readings, on each refresh.
I wouldn't want to do it myself, but putting an R-Pi (or BeagleBone Black* with IoT image installed) at the far end, with an Ethernet cable to
some near end device (which doesn't need to be another R-Pi -- any computer that can SSH into the remote would work for maintenance tasks; and configuring a web-server on the remote could be used for fancier tasks -- especially if one can run node-red [no personal experience] to build a control system) may be viable. Just make sure you don't have power
glitches.
* BBB has more GPIO than an R-Pi, on board eMMC so one doesn't /have/ to
run from uSD card, though that is an option [recommended too as swapping a corrupt SD card is easier than trying to rebuild the eMMC, assuming it
hasn't out-right failed]. Common OS images are Console, IoT, and LXQT --
the X-window system sucks up a lot of space <G>. For an IoT application,
one doesn't need a graphical window environment. And runs essentially
Debian -- not the heavily customized version of the R-Pi.
sb spoke about optoelectronic isolation, sb else told me it
was not necessary.
So I'm at a loss
the valves and the pump are high voltate, but none has big
power consumption. The lowara ecocirc pump absorbs 13-60 W,
the two valves far less.
it does not seem applicable, considered the dozen sensors to
read.
I dunno how much IO pins / sensor will be needed once I
insert a ADC converter amidst
I need to find just libraries to access the IO at low level,
the rest of the SW would be up to me.
For this, simply writing to the sysfs GPIO controls would be fast
enough: https://elinux.org/RPi_GPIO_Code_Samples#sysfs.2C_part_of_the_raspbian_operating_system
Il 03/09/21 12:23, Computer Nerd Kev ha scritto:
In terms of electronics, the demands that you've
specified seem modest enough.
yes nothing amazing, nonetheless overwelming for a complete
ignorant (like me) in electronics.
The Pis are one range amongst many Single Board Computer (SBC)
ranges. I'm not an expert on them, and I mainly look at lists on
this site as a starting point:
https://linuxgizmos.com/150-open-spec-community-backed-linux-sbcs-under-200/
I'll have a look.
I must ad I have long be considering ESP32, but the SW
environment is unfamiliar to me, and I dunno if it can pilot
any kind of display to make mainteinance
Try looking for the word "industrial" on that page for the sort
of board that might be a bit above the Pis in terms of reliability.
It'll generally be easier to develop software for the Pis than for
some obscure industrial-spec SBC though.
you got perfectly the point ! In Debian i feel at home, but
I am completely unfamiliar with ESP32 or Arduino :\
The control cable was standard 3 core mains cable running at 1200baud!
On Fri, 3 Sep 2021 08:59:03 +0200, Soviet_Mario <SovietMario@CCCP.MIR> declaimed the following:
1) read a dozen of temperature detectors (the model of them
have not been determined, maybe some RTD PT100 and some
thermistors, or even some NTC), connected by an "unlimited"
number of 0,22 mm2 copper wires. The detectors will span in
24AWG if my look-up is correct...
a 1-40 m distances (*)
... same look-up gives 76.4ohms/km... or just over 3ohm at 40m That is 3%
of the PT100 "100Ohm at 0degC" -- with two leads that comes to 6% which
needs to be compensated... Not that I'd want to run /any/ analog signal
that distance.
On Fri, 3 Sep 2021 21:32:44 +0100
Folderol <general@musically.me.uk> wrote:
The control cable was standard 3 core mains cable running at 1200baud!
That works well, the first office I worked in had terminals running
at 9600 baud using the lightest 3 core we could find (rated at 1A IIRC), there was only one run where we had to drop to 1200 (over half a roll IIRC) and that nearly ran at 9600 but dropped characters often enough to irritate.
Cutting
to the chase, 1-Wire sensors might be a good option: https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1796.html
https://en.wikipedia.org/wiki/1-Wire https://www.raspberrypi-spy.co.uk/2013/03/raspberry-pi-1-wire-digital-thermometer-sensor/
It would be a good idea to study this document that describes
electrical considerations for long-distance 1-Wire comms: https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/148.html
PDF -https://pdfserv.maximintegrated.com/en/an/AN148.pdf
Personally, I'd use a Raspberry Pi3 combined with an Arduno nano.
The nano has 8 x 10bit A/D converters and 13 no-fuss digital I/O. It also accepts 5V inputs (and they are better protected).
This can do all your basic capture and clean-ups.
You can then pass this on to the Pi (i2c) maybe, or even simple serial.
The Pi can then to all the complex stuff, and manage touch screen I/O etc.
Both can be directly powered from a 5V supply.
-- W J G
Computer Nerd Kev <not@telling.you.invalid> wrote:
For this, simply writing to the sysfs GPIO controls would be fast
enough:
https://elinux.org/RPi_GPIO_Code_Samples#sysfs.2C_part_of_the_raspbian_operating_system
Seems like for such a slow heating application, almost anything is fast enough. He might use Python.
A. Dumas <alexandre@dumas.fr.invalid> wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
For this, simply writing to the sysfs GPIO controls would be fast
enough:
https://elinux.org/RPi_GPIO_Code_Samples#sysfs.2C_part_of_the_raspbian_operating_system
Seems like for such a slow heating application, almost anything is fast
enough. He might use Python.
If he uses the sysfs interface then it doesn't matter what language
he prefers, so long as it has a way of writing to a file (by "fast
enough" I meant fast enough in this application, it's slow compared
to C libraries etc. but that makes no difference for him).
On Fri, 3 Sep 2021 21:32:44 +0100
Folderol <general@musically.me.uk> wrote:
The control cable was standard 3 core mains cable running at 1200baud!
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On Fri, 3 Sep 2021 21:32:44 +0100
Folderol <general@musically.me.uk> wrote:
The control cable was standard 3 core mains cable running at 1200baud!
I once made one of those using a 30m mains extension lead and some 'DB9 to >mains plug' adapters. It worked fine, although I don't think it would have >met H&S :-) There was an extra male mains plug that was very heavily taped
up to prevent anyone plugging it in and making the whole assembly live...
Theo
On Fri, 03 Sep 2021 16:10:23 -0400, Dennis Lee Bieber wrote:
Whether a microcontroller or an embedded Linux board, the interfacingSince you know C, take a look at the poll() function.
with hardware is going to be similar. Embedded Linux is not "real-time",
but with relaxed polling periods that may not be significant. It's not
like you expect to react within 100ns to some interrupt condition.
pol() designed for asynchronous i/o via the filing system over many connections of any type, so its equally good at handling serial, network
or USB connections.
Poll() is given a list of file descriptors as a parameter and waits for
input to arrive from them. No cpu time is used while waiting. When input
is received from any fd, poll() calls the appropriate function to read
and process the input and, when done, waits for and processes the next
input. Because poll() processes each event in arrival sequence, there's
no need to understand multi-threading code, so writing code to use it is straight forward: just use a case statement to call the appropriate
function to handle input from that fd.
The only difference between poll() and ppoll() is that the ppoll() can timeout if no input is received within the timeout interval. poll()
needs to be sent some sort of 'stop now' message to terminate the run.
There's a reasonable description in the poll manpage, but if you have a
copy of "System Progrsmming for UNIX SVR4" by David Curry (pub. O'Reilly),
it or a later version contains an excellent description of how to use
poll().
Yes. I thought your link would be to a C version but that's on another part >of the page. The shell is certainly slow enough ;) I also failed to write >what I meant: there are very convenient Python modules for accessing the
Pi's hardware, and myriad short & simple examples. (Also on that page, but
it seems rather out of date generally, e.g. WiringPi has been retracted by >Gordon.)
Not even a phone line?
In reality you can run plenty of stuff that distance, but not with a
simple plug-n-play hookup
On Sat, 4 Sep 2021 07:46:24 +0100, The Natural Philosopher <tnp@invalid.invalid> declaimed the following:Not between local exchange and consumer, in the UK
Not even a phone line?Not when precision levels are going to be measured -- assuming you can even find a POTS line these days. I'm pretty sure the phone company had repeaters placed at regular intervals: https://en.wikipedia.org/wiki/Repeater#Telephone_repeater
"""c
Voice grade POTS was never rated for "fidelity". It was limited to an equivalent of about 65kbps (US regulations cut that down to about 56kbps, reserving the rest of the bandwidth for signaling functions -- hence the limit on old modems (and even then, it tended to be one way, the other direction ran slower).
Note that even that isn't sent as pure bits, but as
tones consolidating 4 or more bits into each tone. The actual data rate
being limited to around 2400 baud (not bps; with 8 bits per tone, 2400 baud supports a 19200bps rate) ["baud" -> state changes per second; on slower modems using just two tones -- high/low -- baud and bps were the same]
There are companies that still sell loop-current and ring-voltage boosters for long line POTS.
In reality you can run plenty of stuff that distance, but not with a
simple plug-n-play hookup
Sure -- RS-422 differential wiring ( https://en.wikipedia.org/wiki/RS-422 ) is rated for up to 1200m using
twisted pair vs RS-232 ( https://en.wikipedia.org/wiki/RS-232#Cables ) single-ended wiring having an accepted limit of around 15m unless special
low capacitance cables are used (Note: RS-232 properly uses a voltage swing of around 12V; the UARTs on all these single board computers and microcontrollers are NOT RS-232 signals, having voltage swings of 5V or
even 3.3V depending upon the processor; RS-422 is defined with a much lower voltage swing).
And ADSL was fine at 5Mps at 32km
And others. ADSL VDSL , SDSL as well as G.703 are all long distance
(over 100m) protocols that can support high bit rates on twisted pair
As has also been suggested 'one wire' sensors are quite suitable for low
data rates on extremely rubbish cabling
On Sat, 4 Sep 2021 09:10:30 -0000 (UTC), A. Dumas <alexandre@dumas.fr.invalid> declaimed the following:
Yes. I thought your link would be to a C version but that's on another part >>of the page. The shell is certainly slow enough ;) I also failed to write >>what I meant: there are very convenient Python modules for accessing the >>Pi's hardware, and myriad short & simple examples. (Also on that page, but >>it seems rather out of date generally, e.g. WiringPi has been retracted by >>Gordon.)SysFS, I believe, has been deprecated by the Linux OS team -- still there, but supposed to be phasing over to the "character device" mode: https://embeddedbits.org/new-linux-kernel-gpio-user-space-interface/
On Sat, 4 Sep 2021 18:44:47 +0100, The Natural Philosopher <tnp@invalid.invalid> declaimed the following:
And ADSL was fine at 5Mps at 32km
Uses frequencies sets outside the voice-band (voice is <4kHz -- like I said, not rated for "fidelity"). According to one web site, ADSL basically
is running "multiple" modems each within a different frequency band. With 8 "modems" one essentially sends the equivalent of 8 separate phone lines <G>
Thing is, that is still analog (tonal) data being sent. Not pure digital,
which tone is in that "modem" frequency band.*shakes head in wonderment*.
Binary (1/0) not encoded in tones is much more susceptible to line noise, and analog temperature sensors which output voltage in relation to
the temperature are subject to line resistance losses.
And others. ADSL VDSL , SDSL as well as G.703 are all long distanceDSL, as mentioned, is tonal based, not digital -- groups of bits are mapped to audio tones (and another group to another set of audio tones).
(over 100m) protocols that can support high bit rates on twisted pair
As has also been suggested 'one wire' sensors are quite suitable for low
data rates on extremely rubbish cabling
The actual signalling (baud) rate is less than the bps rate seen by the
user.
QAM 16 uses one tone-set to encode 4-bits of data https://en.wikipedia.org/wiki/Quadrature_amplitude_modulation#Digital_QAM
Oh, thanks for that. I only really use either Shell/Bash or C so
SysFS was going to be the basis for a few shell script based
projects. None of which I've actually got around to mind you.
(I'm new to this NG)
the budget not being crucial,
On 2021-09-02 23:59, Soviet_Mario wrote:
(I'm new to this NG)
the budget not being crucial,
then use an RPi4, or a 3b+ if the lead time is too long for a 4.
On 07/09/2021 18:10, Big Bad Bob wrote:
then use an RPi4, or a 3b+ if the lead time is too long for a 4.
Is the RPi4 in short supply?
On 2021-09-02 23:59, Soviet_Mario wrote:
(I'm new to this NG)
the budget not being crucial,
then use an RPi4, or a 3b+ if the lead time is too long for
a 4.
For Analog to digital I suggest setting up a serial
interface to an Arduino and use its analog to digital
converters.
A serial interface
can either use the hardware serial, or
(my preference) just plug the arduino in directly via USB.
You can even program it from the RPi 4 (I think the Arduino
IDE has been builot for the RPi), or you can just use
avrdude from the RPi to upload firmware to the Arduino if
you don't want to move USB cables around.
In any case if you're doing development on the RPi itself,
having a faster one with more RAM will be helpful.
I suggest using ssh to run programs on the RPi. Do not
bother connecting a mouse and keyboard and large screen. If
you use a touch screen this is fine for testing your display
but you won't be able to reasonably do development that
way. So, ssh and use 'DISPLAY=server:0.0' to make X11
applications display on 'server' rather than the RPi touch
screen. The 'server' machine will need to be listening for
TCP X11 connections and also you must use 'xhost' to add the
RPi's IP address to the access list.
Anyway, that's how I'd do it. (and I do quite a bit of ssh
access and running X11 programs on networked workstations to
edit stuff on the RPi while it also has a touch screen I can
test with)
is this compatible with cables of "alarm" type (8x0,22 mm^2)
? I have two of them installed.
I can no longer install further wiring, as the trench has
just been refilled with earth an costipated
o buffer/inverter|&o NAND gate
On Wed, 8 Sep 2021 13:42:43 +0200, Soviet_Mario <SovietMario@CCCP.MIR> >declaimed the following:
is this compatible with cables of "alarm" type (8x0,22 mm^2)
? I have two of them installed.
I can no longer install further wiring, as the trench has
just been refilled with earth an costipated
The cable length is the killer. Regular (single-ended/unbalanced,
RS-232 style) 1) requires three wires: Tx, Rx, and GND; 2) has a /typical/ >maximum run of 50 feet (~16m). True RS-232 specifies +5-15V for "0" and >-5-15V for "1" at the sender, with a minimum of +3V & -3V at the receiver. >The UARTs on most SBCs (embedded Linux boards) and microcontrollers use
board voltage -- 0V and +5V (or +3.3V -- depending on the board, and you
may need to match those at both ends; AVR [Uno] is 5V, ARM Cortex is 3.3V).
RS-422 (double-ended/balanced) requires four wires: Tx+, Tx-, Rx+, Rx-,
which should be done as two sets of twisted pair. It uses lower voltages,
and uses the difference between the + and - leads to determine "0" or "1" >state (which is why there isn't a mandated ground lead, though you should >still have a common ground connection between the local and remote boards). >It supports distances up to 1200m (depending upon signal rate -- shorter >segments -- 10m -- can reach 10Mbps, 1200m is rated for just under
100kbps). Of course, you would have to wire up transceivers to convert the >single-ended UART to double-ended and back. You probably want some buffer
ICs anyway to handle the current load. Something like taking the UART Tx >signal, and feeding it to a pair of inverters, and then feeding the output
of one inverter to a third to get the logical - signal (Use a fixed width >font to view the ASCII art/diagrams):
|------|>o----|>o---- Tx-
Tx -----|
|------|>o----------- Tx+
The first inverter on each side is the buffer to provide higher
current. Use an inverter and NAND gate at the receive end
Tx- ------|>o----------|
|====|&o----- Rx
Tx+ -------------------|
o buffer/inverter|&o NAND gate
Hopefully, at the slow rates in use, the minor delay of the extra inverters >won't cause synch loss -- otherwise you'll need a non-inverting buffer on
the Tx+ lines to better match the delay of the inverter on the other line
USB won't manage the distance. USB2 is rated for 16feet (5m), and USB3
for just over 9feet (3m). To go longer requires "active" cables (which are >basically a cable with a built-in one-port hub in the middle, fed from one >end with power supply; a search found one at just under 100ft (30m) for >US$50).
The folks I used to work for did this for the master control system in a plastics moulding factory, where 16 14M high silos had to be selected to feed 10
moulding machines (each of which had 2-4 'bins'). All over a single cat5e cable
running at 19200 baud.
Folderol <general@musically.me.uk> wrote:
The folks I used to work for did this for the master control system in a
plastics moulding factory, where 16 14M high silos had to be selected to feed 10
moulding machines (each of which had 2-4 'bins'). All over a single cat5e cable
running at 19200 baud.
I think the problem the OP has is he's not got twisted pair - if it's this sort of stuff: https://cpc.farnell.com/pro-power/ac-t3-8c-wht-500m/alarm-cable-8-core-type-3-white/dp/CB20040
then it's just 8 parallel cores, not even screened. Noise is going to be an issue if it's very long.
I don't know what's best in that situation - current loop? Single ended
with a big driver? Running differential and hoping there's not enough differential mode noise (which there might not be, if it's outside)?
You might get away with it if the data rate is low enough.
Unfortunately it means he's going to need some design to deal with the cable issues, on top of whatever he strings on the end of it. So just hooking an off the shelf Arduino/etc isn't going to do it without extra hardware.
Moral of the story is: when digging a trench bury the best cable you can afford, and twice as much as you think you need, as cable is cheap and digging is expensive...
Theo
Moral of the story is: when digging a trench bury the best cable you can >afford, and twice as much as you think you need, as cable is cheap and >digging is expensive...
Moral of the story is: when digging a trench bury the best cable you can >afford, and twice as much as you think you need,
as cable is cheap and digging is expensive...--
Il 07/09/21 19:10, Big Bad Bob ha scritto:
For Analog to digital I suggest setting up a serial
interface to an Arduino and use its analog to digital
converters.
A serial interface
is this compatible with cables of "alarm" type (8x0,22 mm^2)
? I have two of them installed.
On 08 Sep 2021 18:13:34 +0100 (BST), Theo
<theom+news@chiark.greenend.org.uk> declaimed the following:
Moral of the story is: when digging a trench bury the best cable you can
afford, and twice as much as you think you need, as cable is cheap and
digging is expensive...
Or a large conduit (or pair, to separate data from power),
with enough
room to route a long snake and pull additional cables through from one end.
But yes... the OP buried some wires, and /then/ is trying to figure out what signals the wires will support, rather then determining the needs of various communication protocols and burying suitable wires for the
applicable schemes.
Soviet_Mario <SovietMario@cccp.mir> wrote:
Il 07/09/21 19:10, Big Bad Bob ha scritto:
For Analog to digital I suggest setting up a serial
interface to an Arduino and use its analog to digital
converters.
A serial interface
is this compatible with cables of "alarm" type (8x0,22 mm^2)
? I have two of them installed.
Potentially, depending on the "serial interface". But rather than
stuffing around with lots of Arduinos, just use the 1-wire
temperature sensors that I suggested earlier, where most of the
design work has already been done for you, including the serial
interface.
I have to understand better the solution of 1-Wire sensors,
which seems very suitable.
And I must assess which kind of T sensor exist (I need some
immersed in water, some in contact with pipes or metal surfaces)
Il 09/09/21 00:41, Computer Nerd Kev ha scritto:
Soviet_Mario <SovietMario@cccp.mir> wrote:
Il 07/09/21 19:10, Big Bad Bob ha scritto:
For Analog to digital I suggest setting up a serial
interface to an Arduino and use its analog to digital
converters.
A serial interface
is this compatible with cables of "alarm" type (8x0,22 mm^2)
? I have two of them installed.
Potentially, depending on the "serial interface". But rather than
stuffing around with lots of Arduinos, just use the 1-wire
temperature sensors that I suggested earlier, where most of the
design work has already been done for you, including the serial
interface.
sounds perfect. But these 1-wire probes, need their own kind
of cables, or can run smoothly on my cables ?
Il 09/09/21 00:41, Computer Nerd Kev ha scritto:
Soviet_Mario <SovietMario@cccp.mir> wrote:
Il 07/09/21 19:10, Big Bad Bob ha scritto:
For Analog to digital I suggest setting up a serial
interface to an Arduino and use its analog to digital
converters.
A serial interface
is this compatible with cables of "alarm" type (8x0,22 mm^2)
? I have two of them installed.
Potentially, depending on the "serial interface". But rather than
stuffing around with lots of Arduinos, just use the 1-wire
temperature sensors that I suggested earlier, where most of the
design work has already been done for you, including the serial
interface.
sounds perfect. But these 1-wire probes, need their own kind of cables,
or can run smoothly on my cables ?
Soviet_Mario <SovietMario@cccp.mir> wrote:
Il 07/09/21 19:10, Big Bad Bob ha scritto:
For Analog to digital I suggest setting up a serial
interface to an Arduino and use its analog to digital
converters.
A serial interface
is this compatible with cables of "alarm" type (8x0,22 mm^2)
? I have two of them installed.
Potentially, depending on the "serial interface". But rather than
stuffing around with lots of Arduinos, just use the 1-wire
temperature sensors that I suggested earlier, where most of the
design work has already been done for you, including the serial
interface.
In article <Qeh*pVJty@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:
Moral of the story is: when digging a trench bury the best cable you can >>afford, and twice as much as you think you need,
... and a draw-string to pull the newfangled cable/fibre/etc. that you
*now* discover you need despite all the above ;)
as cable is cheap and digging is expensive...
On Wed, 8 Sep 2021 21:14:57 +0100 (BST)
mjb@signal11.invalid (Mike) wrote:
In article <Qeh*pVJty@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:
Moral of the story is: when digging a trench bury the best cable you can >>> afford, and twice as much as you think you need,
... and a draw-string to pull the newfangled cable/fibre/etc. that you
*now* discover you need despite all the above ;)
as cable is cheap and digging is expensive...
First rule of drawing cables:
Always include a new drawstring to replace the one you just pulled the cables with.
On 09/09/2021 02:07, Soviet_Mario wrote:
Il 09/09/21 00:41, Computer Nerd Kev ha scritto:They will run on anything that has more than 1 wire!
Soviet_Mario <SovietMario@cccp.mir> wrote:
Il 07/09/21 19:10, Big Bad Bob ha scritto:
For Analog to digital I suggest setting up a serial
interface to an Arduino and use its analog to digital
converters.
A serial interface
is this compatible with cables of "alarm" type (8x0,22
mm^2)
? I have two of them installed.
Potentially, depending on the "serial interface". But
rather than
stuffing around with lots of Arduinos, just use the 1-wire
temperature sensors that I suggested earlier, where most
of the
design work has already been done for you, including the
serial
interface.
sounds perfect. But these 1-wire probes, need their own
kind of cables, or can run smoothly on my cables ?
The only variable is how long the cable can be before errors
become unacceptable
Soviet_Mario <SovietMario@cccp.mir> wrote:
Il 09/09/21 00:41, Computer Nerd Kev ha scritto:
Soviet_Mario <SovietMario@cccp.mir> wrote:
Il 07/09/21 19:10, Big Bad Bob ha scritto:
For Analog to digital I suggest setting up a serial
interface to an Arduino and use its analog to digital
converters.
A serial interface
is this compatible with cables of "alarm" type (8x0,22 mm^2)
? I have two of them installed.
Potentially, depending on the "serial interface". But rather than
stuffing around with lots of Arduinos, just use the 1-wire
temperature sensors that I suggested earlier, where most of the
design work has already been done for you, including the serial
interface.
sounds perfect. But these 1-wire probes, need their own kind
of cables, or can run smoothly on my cables ?
The Maxim doc, and also this guide: http://midondesign.com/Documents/1-WireApplicationGuide103.pdf
(page 10) Suggest CAT5 cabling for distance over 100ft, but I'd be
inclined to try it with your cable and see - a sensor won't cost
much and software just involves running the commands in the
tutorial that I linked to earlier. Those specs are pretty general
and probably conservative.
One thing that might be important is whether the wires run near
motors and their power cables,
or other electronics for that
matter. Then they're more likely to pick up electrical noise.
Den 2021-09-09 kl. 14:10, skrev Soviet_Mario:
one sensor, the farthest, will be roughly 34 m apart, the second farther
will stand at 28 m distant.
All other sensors will fall in the 1-6 m range.
Il 09/09/21 05:46, Computer Nerd Kev ha scritto:
One thing that might be important is whether the wires run near
motors and their power cables,
no motors nor electroducts.
As to the power cables, i inserted them in another
corrugated pipe, but yes, this latter runs in the same
trench. They might be then just a 10 cm apart (separated by
sand and other corrugated pipes for water flow)
Den 2021-09-09 kl. 14:10, skrev Soviet_Mario:
one sensor, the farthest, will be roughly 34 m apart, the
second farther will stand at 28 m distant.
All other sensors will fall in the 1-6 m range.
Perhaps the easiest would be
* a couple of ESP8266 to read sensor values at the location
of the sensors
* push sensor data via JSONRPC2 (http(s) POST) to the RPI
* post process data as it arrives in the RPI
This I do for monitor air quality in our bedroom
(Wife cold - me wants window open)
the ESP8266 can be coded/treated as an arduino + one part to
connect to wifi.
and the distance you are mentioning should do it.
It then come down to how often yoe need new data.
is it in ms or s or 10s range?
if the latter this will do fine.
And you could connect/push data/disconnect every time in the
ESP if you think you will lose the wifi connection sometimes
this way - no wires in the ground
But regarding the WiFi transmission, I fear one problem : the
transmitter and the receiver do not directly "see" each other in a
straight line. There are trees, and the house building is oriented in a
way that shadows the solar panels frame from being seen from the site
where the "brain" would operate.
And the house walls are 70 cm stone.
Should I assume some reflections would be enough for the signal to be
able to reach the Raspberry ?
Den 2021-09-10 kl. 03:30, skrev Soviet_Mario:
But regarding the WiFi transmission, I fear one problem : the
transmitter and the receiver do not directly "see" each other in a
straight line. There are trees, and the house building is oriented in a
way that shadows the solar panels frame from being seen from the site
where the "brain" would operate.
You should
1) bring out a laptop and test wifi from that location
2) buy and ESP8266 and test - they are cheap
3) be prepared to move the router - or have two - the second on placed
in a better spot
And the house walls are 70 cm stone.
That might be tricky - externa antenna? Second router outdoor? >(waterproofed)
Should I assume some reflections would be enough for the signal to be
able to reach the Raspberry ?
Better test than assume
My setup pushes data once/minute - which is way too much but was easy to do.
All this is vast over complication.
The O/P has already described the cabling
in place which is more than enough for a *simple* serial transmission.
Use whatever sensor type is most convenient at the respective locations, with small modules locally. I mentioned Arduino Nanos because they have lots of I/O
capability, are relatively cheap, and their IDE is simplified C with an extensive range of libraries.
For the main communication with the existing cable I'd use RS485 at 300 baud.Yes that is possible. But you'll need a HAT at the pi side and not too
Finally, such a system is reliable, maintainable, and extensible.
Should I assume some reflections would be enough for the signal to be
able to reach the Raspberry ?
All this is vast over complication. The O/P has already described the cabling in place which is more than enough for a*simple* serial transmAgreed
Use whatever sensor type is most convenient at the respective locations, with small modules locally.With one wire, that is not necessary. The sensors will take power from
I mentioned Arduino Nanos because they have lots of I/O
capability, are relatively cheap, and their IDE is simplified C with an extensive range of libraries.
For the main communication with the existing cable I'd use RS485 at 300 baud. A
twisted pair would have been nice, but it's not necessary at that slow speed.
Finally, such a system is reliable, maintainable, and extensible.
On 10/09/2021 02:30, Soviet_Mario wrote:
Should I assume some reflections would be enough for the signal to be
able to reach the Raspberry ?
Paraphrasing Winnie Ille Pu
"De heffalumpi, semper dubitandum est"
With Wifi, you never know....
wifi or serial or bongo drums
Den 2021-09-10 kl. 13:13, skrev The Natural Philosopher:
On 10/09/2021 02:30, Soviet_Mario wrote:
Should I assume some reflections would be enough for the signal to be
able to reach the Raspberry ?
Paraphrasing Winnie Ille Pu
"De heffalumpi, semper dubitandum est"
With Wifi, you never know....
Actually - you never know with ANY communication unless you have
application level ACK.
With this serial line - how do you when somebody dug of the cable/a plug
was lose/a soldering was bad ?
No way you can know. With any comms the base rule is - use application
level ack if you care about your data.
And in this case - wifi or serial or bongo drums - if no data arrives
within a minute or so - something is wrong. No matter transportation of
data.
Does 1-wire work over long distances on non-twisted cables?
What is best is low data rate single wire,because the sensors are
available that use it with no additional hardware. And no need for
external poqwer. Software can read the sensors many times and eliminate
any errors due to noise
It is a two wire protocol and is self powered. It is exactly designed
for this application whereas RS232/432 et etc are not
Theo <theom+news@chiark.greenend.org.uk> wrote:
Does 1-wire work over long distances on non-twisted cables?
Isn't that only relevant to higher frequency signals? Getting to the right level (and not taking too long to sample/answer) is all it takes for 1-wire
I think.
The Natural Philosopher <tnp@invalid.invalid> wrote:
What is best is low data rate single wire,because the sensors are
available that use it with no additional hardware. And no need for
external poqwer. Software can read the sensors many times and eliminate
any errors due to noise
It is a two wire protocol and is self powered. It is exactly designed
for this application whereas RS232/432 et etc are not
Does 1-wire work over long distances on non-twisted cables? The app note
148 you referred says:
"Network Description
The scope of this document is limited to 1-Wire networks that use
Category 5e, twisted-pair copper wire and have 5V bus power supplied
by the master."
which is a much better standard of cable than the OP has installed.
If you have twisted pair then 1-wire is one of plenty of options.
Theo
The Natural Philosopher <tnp@invalid.invalid> wrote:
What is best is low data rate single wire,because the sensors are
available that use it with no additional hardware. And no need for
external poqwer. Software can read the sensors many times and eliminate
any errors due to noise
It is a two wire protocol and is self powered. It is exactly designed
for this application whereas RS232/432 et etc are not
Does 1-wire work over long distances on non-twisted cables? The app note
148 you referred says:
"Network Description
The scope of this document is limited to 1-Wire networks that use
Category 5e, twisted-pair copper wire and have 5V bus power supplied
by the master."
Il 09/09/21 07:18, The Natural Philosopher ha scritto:
On 09/09/2021 02:07, Soviet_Mario wrote:
Il 09/09/21 00:41, Computer Nerd Kev ha scritto:They will run on anything that has more than 1 wire!
Soviet_Mario <SovietMario@cccp.mir> wrote:sounds perfect. But these 1-wire probes, need their own kind of
cables, or can run smoothly on my cables ?
The only variable is how long the cable can be before errors become
unacceptable
one sensor, the farthest, will be roughly 34 m apart, the second farther
will stand at 28 m distant.
All other sensors will fall in the 1-6 m range.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 371 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 37:33:35 |
| Calls: | 7,932 |
| Calls today: | 2 |
| Files: | 12,998 |
| Messages: | 5,805,631 |