• choice of the most fit Raspberry version

    From Soviet_Mario@3:770/3 to All on Fri Sep 3 08:59:03 2021
    (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


    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@3:770/3 to All on Fri Sep 3 10:03:21 2021
    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




    --
    Björn
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to SovietMario@cccp.mir on Fri Sep 3 07:42:32 2021
    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.

    --
    __ __
    #_ < |\| |< _#
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Fri Sep 3 09:09:03 2021
    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 ;-)


    --
    “It is hard to imagine a more stupid decision or more dangerous way of
    making decisions than by putting those decisions in the hands of people
    who pay no price for being wrong.â€

    Thomas Sowell
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Computer Nerd Kev on Fri Sep 3 11:04:53 2021
    Computer Nerd Kev wrote on 03-09-2021 at 09:42:
    Soviet_Mario <SovietMario@cccp.mir> wrote:
    3) log data on a ext4 usb key

    They've all got USB so that's easy.

    Although writing a usb mass storage + ext4 driver for the Pico might be
    a challenge.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 3 11:39:52 2021
    Il 03/09/21 09:42, Computer Nerd Kev ha scritto:
    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.

    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





    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 3 11:52:43 2021
    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





    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 3 11:46:44 2021
    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







    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 3 11:49:07 2021
    Il 03/09/21 11:46, Soviet_Mario ha scritto:
    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.

    sorry, I made a mistake. This abundance of wiring was
    installed for just the 3 more distant PT100 detectors as I
    had to dig a trench and lay cables.
    The nearer ones would be managed as needed, so regardless of
    whatever else, the available wiring will not become a bottleneck


    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









    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David Taylor@3:770/3 to All on Fri Sep 3 11:08:17 2021
    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+

    --
    Cheers,
    David
    Web: http://www.satsignal.eu
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to SovietMario@cccp.mir on Fri Sep 3 10:23:36 2021
    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.

    --
    __ __
    #_ < |\| |< _#
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to SovietMario@cccp.mir on Fri Sep 3 13:04:30 2021
    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Fri Sep 3 12:36:51 2021
    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

    --
    There is nothing a fleet of dispatchable nuclear power plants cannot do
    that cannot be done worse and more expensively and with higher carbon
    emissions and more adverse environmental impact by adding intermittent renewable energy.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 3 15:02:22 2021
    Il 03/09/21 12:23, Computer Nerd Kev ha scritto:
    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.

    oh ... I see. As it seemd unessential, I overlooked this.
    It is simple in brief.
    I have an insulated 5000 L "water buffer"
    There are coils in corrugated steel pipes (heat exchangers)
    that can input heat from two distinct source, in parallel to
    one another : a biomass kiln and solar panels.

    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).


    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.


    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/


    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 :\




    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 3 15:13:22 2021
    Il 03/09/21 13:36, The Natural Philosopher ha scritto:
    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.

    have you seen my calculations and solution ?
    the system will work as expected, more or less reliably.


    Experience suggest it will save no money

    this is uncertain, as I have just spent a lot for materials.
    But I have spared on manwork as I built it all alone. I have
    trees and collect wood for free, and the sun is also for
    free, so at a certain point I will cease to buy very costly
    LPG (upwards of 1'200 ¤/y) and will only spend sth in
    mainteinance. All is very modular and most materials will
    last beyond my life expectancy.

    The inox coils are protected by passive magnesium cathode
    and also by forced current titanium anode.

    The most vulnerable part is the black rubber mat (a couple
    of pool heaters) which won't be exposed directly to UV
    though, as in the front stands a triple layer transparent
    alveolar polycarbonate.
    It might last 5 to 10 years, this is uncertain. The mats
    cost 350 ¤ both.

    the buffer is thick polyethylene, the insulation rock wool.

    the kiln is plain iron, but the exchangers are 6 mm thick
    and should almost survive myself.


    and will certainly
    not save the planet.

    I see


    OTOH if you are selling

    absolutely no, all hand made, for myself alone. I am seeking
    energetic autharchy

    such systems to gullible greentards,
    it will probably make a profit




    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 3 15:14:48 2021
    Il 03/09/21 12:08, David Taylor ha scritto:
    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+


    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.


    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 3 15:23:22 2021
    Il 03/09/21 14:04, Theo ha scritto:
    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.

    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.


    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.

    I'll do the search, but I haven't got very well the meaning.
    The two projects are independent ?

    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.

    uh ! Fine !!!!

    tnx a lot.
    Sure basing over an existing working project and making
    minor adjustment would be faster and safer for a niubbo like
    me !

    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) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Fri Sep 3 10:38:21 2021
    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...


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Fri Sep 3 11:56:40 2021
    On Fri, 3 Sep 2021 15:02:22 +0200, Soviet_Mario <SovietMario@CCCP.MIR> declaimed the following:

    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).

    Take 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).

    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]).


    you got perfectly the point ! In Debian i feel at home, but
    I am completely unfamiliar with ESP32 or Arduino :\

    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.

    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.


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David Taylor@3:770/3 to All on Fri Sep 3 17:12:01 2021
    On 03/09/2021 14:14, Soviet_Mario wrote:
    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.

    I suggest the Pi because it is very well supported, with lots of libraries and help out there. Possibly some of the libraries are more focussed on Python, and I've used Perl and scripting too.
    --
    Cheers,
    David
    Web: http://www.satsignal.eu
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to All on Fri Sep 3 17:19:49 2021
    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Fri Sep 3 17:37:59 2021
    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.

    --
    Outside of a dog, a book is a man's best friend. Inside of a dog it's
    too dark to read.

    Groucho Marx
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 3 21:06:35 2021
    Il 03/09/21 18:19, Folderol ha scritto:
    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.


    recommendation added to the wishlist
    tnx

    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Fri Sep 3 14:20:17 2021
    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.





    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 3 21:12:45 2021
    Il 03/09/21 18:37, The Natural Philosopher ha scritto:
    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.

    I know. Above 50° the aragonite starts crystalizing from
    soluble bicarbonates. I must say technical water in the
    exchanger circuit is totally separated from both the bulk
    storage (5000 L + other 350 L), and from the drinkable circuit.

    As only evaporation is to be reintegrated (but the
    reservoire is 1,5 m above the top of the chimney and not
    heated in any way, and covered, evaporation should be
    modest), the same volume would run in the critical exchangers

    You really need a water softener.

    I will add some poliphosphate. From time to time, should I
    meet performance decline, I'd empty the circuit and rinse
    with dilute phosphoric acid or citric acid and remove rust
    and CaCO3. I don't expect FREQUENT runaways, also.




    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 3 21:05:22 2021
    Il 03/09/21 17:56, Dennis Lee Bieber ha scritto:
    On Fri, 3 Sep 2021 15:02:22 +0200, Soviet_Mario <SovietMario@CCCP.MIR> declaimed the following:

    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).

    Take 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).

    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]).


    you got perfectly the point ! In Debian i feel at home, but
    I am completely unfamiliar with ESP32 or Arduino :\

    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.

    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).


    tnx for this long and deep comparison. I'll try to go
    through it again to fix some ideas


    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.

    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.

    Your application probably doesn't need the fastest response times so slower

    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





    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Fri Sep 3 16:10:23 2021
    On Fri, 3 Sep 2021 21:05:22 +0200, Soviet_Mario <SovietMario@CCCP.MIR> declaimed the following:


    tnx for this long and deep comparison. I'll try to go
    through it again to fix some ideas

    My other post, on cable length limits, will probably have some influence...


    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.

    Most logging (to SD card) on microcontrollers is a simple function. The development libraries all support some sort of SD card file driver and
    simple read/write commands -- if it doesn't have full C printf()
    formatting, it will have print(str), print(int), print(float)...

    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.

    That sounds more like post processing, done on a full computer after swapping out the SD card (probably want one button/GPIO to trigger "dismount"/"mount" of the card <G>.


    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.

    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.

    Consider: https://learn.adafruit.com/experimenters-guide-for-metro
    (this is a 5V AVR-based clone of the Arduino UNO, not to be confused with
    the 3.3V Metro M4 Express which has the same pin-out, but is ARM Cortex M4f processor running CircuitPython natively [and is fast enough that
    CircuitPython might be as fast as compiled AVR code <G>])
    I point that out as it has a chapter using a TMP36 temperature sensor
    (analog output, there are 6 analog inputs on the board). It also has a
    chapter for the common 2line x 16char Hitachi type LCDs -- with some local
    push buttons and that display you could set up some local configuration facility (but if you don't have an SD card or EEPROM to record the configuration, any power glitch will reset to whatever was coded in the program). Take a look at CIRC03, CIRC07, CIRC10, CIRC14 and CIRC15 -- most
    of those are similar for all systems (different library calls, and if you
    don't have ADC on-board you'd have to find code for reading an external
    ADC).

    SD card interface AND battery-backed real-time clock: https://www.adafruit.com/product/1141

    https://learn.adafruit.com/adafruit-mcp9601 (need one per thermocouple,
    with resistors to set individual addresses.

    I don't have time to crawl through all of https://learn.adafruit.com/ but you should find some other tutorials that can give you ideas. I should advise that, with regards to embedded Linux boards, Adafruit is
    transitioning from custom libraries to using an adapter for CircuitPython libraries <G>.




    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





    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to All on Fri Sep 3 21:32:44 2021
    Don't underestimate RS232 data transfer. A radio amateur friend of mine had a steerable aerial array on a 100ft tower. The aerial cables where properly (expensively) shielded. The control cable was standard 3 core mains cable running at 1200baud! That not only managed the orientation but also switching various elements in or out.

    There seems to be no reason you'd want especially fast communication so the same idea should work for your project.

    --
    W J G
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Dennis Lee Bieber on Fri Sep 3 20:50:17 2021
    On Fri, 03 Sep 2021 16:10:23 -0400, Dennis Lee Bieber wrote:

    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.

    Since you know C, take a look at the poll() function.

    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().


    --
    --
    Martin | martin at
    Gregorie | gregorie dot org
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to SovietMario@cccp.mir on Fri Sep 3 23:01:34 2021
    Soviet_Mario <SovietMario@cccp.mir> wrote:
    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

    I've not used them, but I have my eye on these:

    https://www.az-delivery.uk/products/az-touch-wandgehauseset-mit-2-8-zoll-touchscreen-fur-esp8266-und-esp32
    the web shop doesn't work for me, but also on ebay: https://www.ebay.de/itm/144092109467

    and https://shop.m5stack.com/collections/stack-series/products/m5stack-core2-esp32-iot-development-kit
    (also cheaper ones with slightly fewer features)

    which are addon modules with a display. The main thing I like is they're in
    a nice enclosure that you could mount on your wall and it look like a commercial product, rather than a homebrew thing with wires everywhere.

    (In the AZ-touch case you have to mount an ESP module on the PCB as there
    isn't one inside, in the M5 one of the 'stack' boards has the
    microcontroller integrated)

    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 :\

    I'd suggest it's not worth looking at 'industrial' products unless you're
    doing this in volume, or the environment is really hostile (temperature,
    dust etc). They are typically more hassle to work with, especially if
    you're not building thousands of the things. IMHO reliability is more of a problem with software misbehaving than hardware faults.

    Theo
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to SovietMario@cccp.mir on Fri Sep 3 22:45:04 2021
    Soviet_Mario <SovietMario@cccp.mir> wrote:
    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.

    That's your passive safety backup, but I'd suggest putting a system which
    lives on top of that that maintains a habitable environment, and making that
    as simple as possible - fewer chances of things going wrong.

    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.

    ESP32 has wifi, so you just join them on the same wifi network and they communicate (eg via a web interface or MQTT). I believe Home Assistant can autodiscover nodes running ESPHome.

    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 ?

    Home Assistant recently took over/merged ESPHome, so they're two separate projects that integrate well together, written by the same people.

    Home Assistant runs on the Pi and does the web GUI stuff as well as talking
    to all the cloud stuff (Alexa etc). It also has integrations plugins for a whole lot of third party products (Philips Hue, Tuya SmartLife, Alexa, Nest, boilers, heat pumps, electric car chargers, solar PV inverters, enormous quantities of stuff). https://www.home-assistant.io/integrations/

    ESPHome runs on the microcontroller and has a minimalist web interface
    ('off', 'on', '16C') and a set of drivers for lots of sensor and control hardware (like I2C temperature chips and so on). You just configure it with JSON 'I have an BMC280 sensor on pin X called Kitchen_Temp' and it makes a sensor node for that. You flash that firmware to the ESP.

    Then Home Assistant autodetects the sensor node and makes a Kitchen_Temp
    icon in its GUI for it. And you can then set a rule to say 'if kitchen temperature below 12C send me a phone notification' or whatever.

    Theo
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Sat Sep 4 00:23:34 2021
    Il 03/09/21 16:38, Dennis Lee Bieber ha scritto:
    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

    tnx ...

    For sensors that use I2C or SPI -- you will have to determine how many sensors you need to address.

    a dozen, not necessarily of the same type

    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.

    sorry I dunno anything about this, even If I am trying to
    read wiki around



    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

    sb spoke about optoelectronic isolation, sb else told me it
    was not necessary.
    So I'm at a loss

    (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.

    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.




    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.

    yes that was an actractive feature !

    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...

    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


    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...

    I need to find just libraries to access the IO at low level,
    the rest of the SW would be up to me.





    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Sat Sep 4 00:34:17 2021
    Il 03/09/21 20:20, Dennis Lee Bieber ha scritto:
    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...

    sorry I don't understand :\


    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.

    I am reading about FOUR WIRE RTG connection, but I dunno the
    scheme for the insertion of the ADC. In other words, I dunno
    whether is better to send the signal in compensated analog,
    and convert it centrally, or the other way around.


    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.

    the cables are now unmodifiable as they have been "buried"
    in the ground.
    I can use two 8x0,22 mm2 poles and one 3x2,5 mm2 poles for
    power. This for the 2-3 DISTANT sensors.
    The other, closer to the control unit, will be served later
    with proper 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;

    could this solution still be adapted to the available
    wirings ? I don't have a serial cable installed in the track

    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.

    and I have not laid down an ethernet too ...


    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

    alas such wiring was abandoned before filling the track.
    I had never heard about BeagleBone Black ... I'll do some search

    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.



    tnx for all, I have to study a lot before being able to just
    form a vague idea of this all in my mind
    :\






    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Fri Sep 3 20:23:24 2021
    On Sat, 4 Sep 2021 00:23:34 +0200, Soviet_Mario <SovietMario@CCCP.MIR> declaimed the following:


    sb spoke about optoelectronic isolation, sb else told me it
    was not necessary.
    So I'm at a loss

    I think I'd agree that opto-isolation may be going too far... Relays where the 220V circuit does not connect to the switching side should be sufficient -- though you may need to put in protection diodes to block
    reverse EMF when the relay is de-energized (the drop in power through the switching coil can produce a voltage spike).

    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.

    You'll still need to match the "powered" side of the relay to the load, while matching the switching side to the controller circuit (you may even
    need to use a small transistor to channel the power needed to hold the switching side).

    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


    IF used, an I2C ADC will require two lines (clock and data), and the chip may handle from 4 to 8 separate analog inputs -- you address the chip
    and then specify which input to read (or, perhaps, it reads all in
    sequence).

    I need to find just libraries to access the IO at low level,
    the rest of the SW would be up to me.

    If using Python as the language (your speed requirements don't seem to mandate using C/C++) there are a number of GPIO bindings on the R-Pi

    A SPI-based example for analog input https://projects.raspberrypi.org/en/projects/physical-computing/13
    uses what I think is the current preferred R-Pi Python interface https://gpiozero.readthedocs.io/en/stable/

    Beneath gpiozero are things like pigpio https://abyz.me.uk/rpi/pigpio/ which has both C and Python interfaces.


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Computer Nerd Kev on Sat Sep 4 02:49:04 2021
    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.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to SovietMario@cccp.mir on Sat Sep 4 02:37:28 2021
    Soviet_Mario <SovietMario@cccp.mir> wrote:
    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.

    If you're completely ignorant about electronics then reading the
    temperature sensors will probably be your biggest problem. 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

    Relays are simple, but if you don't know electronics at all then
    you'd be best using a pre-built relay board like this: https://raspberry.piaustralia.com.au/products/relay-4-zero-4-channel-relay-board-for-pi-zero

    But not that one because it's only 120V rated, it was just the
    first link I clicked on from a web search for "raspberry pi gpio
    relay board". You can pick up the search from there.

    There are many libraries for controlling the GPIO pins for turning
    the relays on/off, see here:
    https://elinux.org/RPi_GPIO_Code_Samples

    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

    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 :\

    Yeah, I'd stick with the Pis, and specifically still a Pi Zero W
    in my opinion. I assumed this was part of some industrial process
    (and to be honest, that you'd probably taken on a job you weren't
    qualified for) where if it went wrong there'd be a factory grind
    to a halt, or flood. Now that you've explained what it is, I see
    that using a Pi isn't such a high-risk proposition.

    Even if reliability is a concern, you could set up a second Pi
    which monitors the first and takes over if it goes down. That
    introduces some more complexity in the electronics though.

    --
    __ __
    #_ < |\| |< _#
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Folderol on Sat Sep 4 06:14:46 2021
    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.

    --
    Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun
    The computer obeys and wins. | licences available see
    You lose and Bill collects. | http://www.sohara.org/
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Dennis Lee Bieber on Sat Sep 4 07:46:24 2021
    On 03/09/2021 19:20, Dennis Lee Bieber wrote:
    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.

    Not even a phone line?

    In reality you can run plenty of stuff that distance, but not with a
    simple plug-n-play hookup





    --
    Labour - a bunch of rich people convincing poor people to vote for rich
    people by telling poor people that "other" rich people are the reason
    they are poor.

    Peter Thompson
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Sat Sep 4 07:48:13 2021
    On 04/09/2021 06:14, Ahem A Rivet's Shot 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!

    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.

    back in the day whole companies were wired with serial terminals. 9600
    goes a long way.

    --
    “The urge to save humanity is almost always only a false face for the
    urge to rule it.â€
    – H. L. Mencken
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Computer Nerd Kev on Sat Sep 4 08:06:47 2021
    On 04/09/2021 03:37, Computer Nerd Kev wrote:
    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

    I absolutely think you have found the optimal solution
    1 wire temperature sensors are easily found (https://www.mouser.co.uk/_/?keyword=DS18B20) , and a Pi zero 'one wire
    HAT' is available (https://thepihut.com/products/1-wire-pizero)
    as well as mains voltage relays (https://thepihut.com/collections/raspberry-pi-relay-hats/products/four-relays-four-inputs-8-layer-stackable-card-for-raspberry-pi)

    1 wire SHOULD do the distance. Not much else will.



    --
    No Apple devices were knowingly used in the preparation of this post.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David Taylor@3:770/3 to Folderol on Sat Sep 4 07:38:49 2021
    On 03/09/2021 17:19, Folderol wrote:
    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

    Excellent idea!

    --
    Cheers,
    David
    Web: http://www.satsignal.eu
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to A. Dumas on Sat Sep 4 07:11:31 2021
    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).

    --
    __ __
    #_ < |\| |< _#
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Computer Nerd Kev on Sat Sep 4 09:10:30 2021
    Computer Nerd Kev <not@telling.you.invalid> wrote:
    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).

    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.)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Ahem A Rivet's Shot on Sat Sep 4 10:39:30 2021
    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to Theo on Sat Sep 4 13:50:44 2021
    On 04 Sep 2021 10:39:30 +0100 (BST)
    Theo <theom+news@chiark.greenend.org.uk> wrote:

    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

    I really miss the days when you could quickly patch something together and it would 'Just Work' (tm).

    --
    W J G
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Sat Sep 4 16:35:30 2021
    Il 03/09/21 22:50, Martin Gregorie ha scritto:
    On Fri, 03 Sep 2021 16:10:23 -0400, Dennis Lee Bieber wrote:

    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.

    Since you know C, take a look at the poll() function.

    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().




    TNX !

    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Sat Sep 4 10:50:18 2021
    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/

    Some of the language specific utility libraries may have already converted over behind the scenes.


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Sat Sep 4 11:33:23 2021
    On Sat, 4 Sep 2021 07:46:24 +0100, The Natural Philosopher <tnp@invalid.invalid> declaimed the following:

    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
    """
    In the 1950s negative impedance gain devices were more popular, and a transistorized version called the E6 repeater was the final major type used
    in the Bell System before the low cost of digital transmission made all
    voice band repeaters obsolete.
    ""
    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).



    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Dennis Lee Bieber on Sat Sep 4 18:44:47 2021
    On 04/09/2021 16:33, Dennis Lee Bieber wrote:
    On Sat, 4 Sep 2021 07:46:24 +0100, The Natural Philosopher <tnp@invalid.invalid> declaimed the following:

    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
    Not between local exchange and consumer, in the UK

    And ADSL was fine at 5Mps at 32km



    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).

    That was because the onward backbone transmission was 64kbps digital

    The actual copper as anyone with ADSL can tell you is well capable of up
    to 20Mbps over reasonably short (sub 1km) distances

    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.


    Nor really in th9s country. Not allowed.


    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 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

    Just because it never gad a port on your computer doesn't mean it
    doesn't exist.

    Data transmission over random bits of less than ideal wire is - or was -
    very big business.

    Thank Clapton I now have an optical fibre coming into my house....

    But in the context of what the OP wants to do, it looks like 'one wire'
    sensors are likely to be the simplest approach, and since data rates can
    be well down below 1 baud, there shouldn't be any real issues

    --
    "In our post-modern world, climate science is not powerful because it is
    true: it is true because it is powerful."

    Lucas Bergkamp
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Sat Sep 4 14:47:17 2021
    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, and the level of the tone may not matter, just enough to detect
    which tone is in that "modem" frequency band.

    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 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

    DSL, as mentioned, is tonal based, not digital -- groups of bits are mapped to audio tones (and another group to another set of audio tones).
    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


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Dennis Lee Bieber on Sun Sep 5 01:19:44 2021
    Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
    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/

    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.

    --
    __ __
    #_ < |\| |< _#
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Dennis Lee Bieber on Sun Sep 5 09:20:09 2021
    On 04/09/2021 19:47, Dennis Lee Bieber wrote:
    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,

    and what is 'pure digital'? analogue voltages are somehow not digital?
    try telling that to a gate designer...

    I am merely making the point that a twisted pair is well capable of far
    higher data rates than you suggested.

    How it does it is weaselling.

    If you understood communication theory you would realise that in the end
    it is limited by bandwith width and signal to noise ratio - moudulation schemata are simply a way to approach that limit.

    and the level of the tone may not matter, just enough to detect
    which tone is in that "modem" frequency band.
    *shakes head in wonderment*.

    Its a bit more complex than that.

    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.

    Oh dear. You REALLY need to read up on Shannon.

    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

    DSL, as mentioned, is tonal based, not digital -- groups of bits are mapped to audio tones (and another group to another set of audio tones).
    The actual signalling (baud) rate is less than the bps rate seen by the
    user.

    You are talking out of your anal orifice. ANY digital signal is in the
    end encoded in analogue. The maximum theoretical transmission rate is
    set by power level attenuation, noise and frequency bandwidth of the
    link. It has NOTHING to do with how you modulate it: THAT is chosen as a
    way of dealing with non random noise.


    QAM 16 uses one tone-set to encode 4-bits of data https://en.wikipedia.org/wiki/Quadrature_amplitude_modulation#Digital_QAM



    So what?

    It has to do that because it has to coexist with baseband audio. And
    deal with LW, MW and SW transmissions. That are very narrow band
    interference at constant phase. Using frequency bins and phase
    modulations makes the best of dealing with that interference.

    But G703.2 is baseband serial. A piece of Ethernet cable is baseband
    serial. Data rates per unit power and distance are similar.

    The limit is governed by Shannon's law*.

    Telephone Modems are limited to 56kbps because baseband audio was
    encoded into a TDM 64kbps digital stream for long distance switched
    telephony.

    They do not represent anything more than a way to utilise the properties
    of that digital audio channel effectively and deal with telephone line
    noise in the baseband. They most certainly do NOT represent the
    limitations of the copper pairs themselves.

    Given that the OP needs are satisfied with an extraordinarily slow data
    rate, the cable will do the job: that is not the problem. The problem is finding the simplest and cheapest technology to utilise it. One wire is probably it. -------------------------------------------------------------------------

    *Shannon's law is stated as shown below: C = B log2< (1 + S/N) where: C
    is the highest attainable error-free data speed in bps that can be
    handled by a communication channel. B is the bandwidth of the channel in
    hertz. S is the average signal power received over the bandwidth
    calculated in watts (or volts squared). N is the average interference
    power or noise over the bandwidth calculated in watts (or volts squared)
    S/N is the signal-to-noise ratio (SNR) of the communication signal to
    the Gaussian noise interference depicted as the linear power ratio. The function log2 signifies the base-2 logarithm. All logarithms are
    exponents. Assuming that x and y are two numbers, the base-2 logarithm
    of x is y, provided that 2y = x. Shannon’s explanation of information
    for communication networks helps to identify the important relationships between several network elements. Shannon’s equations helps engineers determine the amount of information that could be carried over the
    channels associated with an ideal system. Shannon’s is still the base
    for engineers and communication scientists in their never-ending quest
    for faster, more robust, and more energy-efficient communication
    systems. He showed the data compression principles mathematically and
    also showed how controlled error rates can be used to assure integrity
    when information is carried over noisy channels. Practical
    communications systems that can be operated close to the theoretical
    speed limit described by Shannon's law have not yet been devised. Some
    systems that employ advanced encoding and decoding are able to achieve
    50 percent of the limit specified by the Shannon for a channel with
    fixed signal-to-noise ratio and bandwidth.

    --
    When plunder becomes a way of life for a group of men in a society, over
    the course of time they create for themselves a legal system that
    authorizes it and a moral code that glorifies it.

    Frédéric Bastiat
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Sun Sep 5 11:49:33 2021
    On Sun, 5 Sep 2021 01:19:44 -0000 (UTC), not@telling.you.invalid (Computer
    Nerd Kev) declaimed the following:


    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 don't know what pigpio uses internally -- it tends to require a daemon module started with "sudo", and the application libraries use either sockets or pipes to talk to the daemon.

    https://abyz.me.uk/rpi/pigpio/faq.html
    Has a command-line "pigs" program, or can be used similar to sysfs (that
    is: echo commands >pipe, cat results...)

    """
    pigs
    pigs r 4

    pipe I/F
    echo "r 4" >/dev/pigpio
    cat /dev/pigout
    """

    Has fairly detailed C and Python libraries.

    {The R-Pi has way too many I/O options... <G>, some of which probably use
    sysfs behind the scenes if they haven't been updated to char-dev}


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Big Bad Bob@3:770/3 to All on Tue Sep 7 10:10:02 2021
    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)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From gareth evans@3:770/3 to Big Bad Bob on Tue Sep 7 20:51:44 2021
    On 07/09/2021 18:10, Big Bad Bob wrote:
    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.

    Is the RPi4 in short supply?
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to gareth evans on Tue Sep 7 20:20:33 2021
    gareth evans <headstone255@yahoo.com> wrote:
    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?

    Yeah, I don't think so? Also, a 2 GB Pi 4 is now the same price as the old
    1 GB Pi 3. Of course it draws more power and generate more heat, so that
    might be drawbacks in an industrial environment (because it or its power
    supply might fail earlier).
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Wed Sep 8 13:42:43 2021
    Il 07/09/21 19:10, Big Bad Bob ha scritto:
    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

    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

    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)



    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Wed Sep 8 11:34:55 2021
    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).



    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to Dennis Lee Bieber on Wed Sep 8 17:46:21 2021
    On Wed, 08 Sep 2021 11:34:55 -0400
    Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

    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).





    You can get dedicated uart->422 chips. They're cheap as err. chips :)

    However, if you're doing that, a much better option is RS485.

    If you're running 485 you can daisy chain multiple modules and run a master-slave setup. With such as the MAX3082

    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 was partly involved in the design, and one of the other guys was a topography wizard and worked out the shortest possible route that was actually achievable. This still used most of a 300M drum!


    --
    W J G
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Folderol on Wed Sep 8 18:13:34 2021
    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Theo on Wed Sep 8 18:35:19 2021
    On 08/09/2021 18:13, Theo wrote:
    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

    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

    The pi can take a '1 wire' hat



    --
    "And if the blind lead the blind, both shall fall into the ditch".

    Gospel of St. Mathew 15:14
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Wed Sep 8 15:29:23 2021
    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.


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Mike@3:770/3 to theom+news@chiark.greenend.org.uk on Wed Sep 8 21:14:57 2021
    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...
    --
    --------------------------------------+------------------------------------ Mike Brown: mjb[-at-]signal11.org.uk | http://www.signal11.org.uk
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to SovietMario@cccp.mir on Wed Sep 8 22:41:25 2021
    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.

    --
    __ __
    #_ < |\| |< _#
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Thu Sep 9 03:05:37 2021
    Il 08/09/21 21:29, Dennis Lee Bieber ha scritto:
    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),

    yes power cable (3 poles) has its "corrugated pipe" and the
    two (8 poles each) data signal has another.
    I have no idea whether or not they are close or separated
    withing the trench, even if I tried to fasten them with
    nylon straps separated by the two plastic WATER pipes ...

    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)

    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.




    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Thu Sep 9 03:07:21 2021
    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 ?




    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Wed Sep 8 22:21:54 2021
    On Thu, 9 Sep 2021 03:05:37 +0200, Soviet_Mario <SovietMario@CCCP.MIR> declaimed the following:



    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)

    Pure contact types (ignoring cable matters) should not be a concern. Bare chip types, OTOH, may not be compatible with immersion -- they are
    more ambient air systems (HVAC thermostats, etc.).

    Immersion types tend to have a stainless steel "probe" with a length of wiring.

    For all types, you need to consider the temperature range the sensor can handle.

    Some "1-wire" device still need a ground and +V supply line -- the "1-wire" applies to the commanding and return signal being on a shared data line. The protocol to command, and receive values, may need to be
    bit-banged -- the SBC may not have the protocol as an "inherent" feature.

    Review: https://docs.onion.io/omega2-maker-kit/starter-kit-temp-sensor.html



    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to SovietMario@cccp.mir on Thu Sep 9 03:46:52 2021
    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.

    --
    __ __
    #_ < |\| |< _#
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Thu Sep 9 06:18:02 2021
    On 09/09/2021 02:07, Soviet_Mario 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 ?

    They will run on anything that has more than 1 wire!

    The only variable is how long the cable can be before errors become unacceptable








    --
    “it should be clear by now to everyone that activist environmentalism
    (or environmental activism) is becoming a general ideology about humans,
    about their freedom, about the relationship between the individual and
    the state, and about the manipulation of people under the guise of a
    'noble' idea. It is not an honest pursuit of 'sustainable development,'
    a matter of elementary environmental protection, or a search for
    rational mechanisms designed to achieve a healthy environment. Yet
    things do occur that make you shake your head and remind yourself that
    you live neither in Joseph Stalin’s Communist era, nor in the Orwellian utopia of 1984.â€

    Vaclav Klaus
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Computer Nerd Kev on Thu Sep 9 06:16:26 2021
    On 08/09/2021 23:41, Computer Nerd Kev wrote:
    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.

    +1

    --
    “it should be clear by now to everyone that activist environmentalism
    (or environmental activism) is becoming a general ideology about humans,
    about their freedom, about the relationship between the individual and
    the state, and about the manipulation of people under the guise of a
    'noble' idea. It is not an honest pursuit of 'sustainable development,'
    a matter of elementary environmental protection, or a search for
    rational mechanisms designed to achieve a healthy environment. Yet
    things do occur that make you shake your head and remind yourself that
    you live neither in Joseph Stalin’s Communist era, nor in the Orwellian utopia of 1984.â€

    Vaclav Klaus
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to Mike on Thu Sep 9 07:51:16 2021
    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.

    --
    W J G
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Thu Sep 9 14:06:12 2021
    Il 09/09/21 08:51, Folderol ha scritto:
    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.


    actually I drew strings, but I'm almost certain that
    friction would prevent pulling other cables while holding
    the existing still. The corrugated pipe is rather small and
    just contains two cables.
    :\
    Now I will read the Onion related documentation from Mr
    Bieber ...


    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Thu Sep 9 14:10:54 2021
    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:
    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 ?

    They will run on anything that has more than 1 wire!

    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.











    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Thu Sep 9 14:08:52 2021
    Il 09/09/21 05:46, Computer Nerd Kev ha scritto:
    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,

    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)

    or other electronics for that
    matter. Then they're more likely to pick up electrical noise.


    tnx

    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@3:770/3 to All on Thu Sep 9 14:34:40 2021
    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

    --
    Björn
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to SovietMario@cccp.mir on Thu Sep 9 23:13:03 2021
    Soviet_Mario <SovietMario@cccp.mir> wrote:
    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)

    That's not ideal, but could be worse. Again I'd suggest testing
    reading a sensor while motors are running. If there's an issue
    when the motors are on, you might consider fitting an EMI filter
    like this to them:
    https://www.jaycar.com.au/240v-ac-emi-filter/p/MS4001

    --
    __ __
    #_ < |\| |< _#
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Soviet_Mario@3:770/3 to All on Fri Sep 10 03:30:13 2021
    Il 09/09/21 14:34, Björn Lundin ha scritto:
    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?

    even 1 datum per minute would be more than enough.
    All the component have quite high thermal inertia (tens of
    liters water in the circuit plus another 10 L in the
    pressure equalizer, 5000+380 in the storage buffers).

    No need for a fast pace.

    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 ?

    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



    --
    1) Resistere, resistere, resistere.
    2) Se tutti pagano le tasse, le tasse le pagano tutti
    Soviet_Mario - (aka Gatto_Vizzato)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@3:770/3 to All on Fri Sep 10 09:49:54 2021
    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.



    --
    Björn
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to b.f.lundin@gmail.com on Fri Sep 10 09:54:02 2021
    On Fri, 10 Sep 2021 09:49:54 +0200
    Björn Lundin <b.f.lundin@gmail.com> wrote:

    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. 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.

    --
    W J G
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@3:770/3 to All on Fri Sep 10 11:45:24 2021
    Den 2021-09-10 kl. 10:54, skrev Folderol:

    All this is vast over complication.

    Is it? using a pi and the ESP + a router You got everything you need.
    No adapters. no HATS. just use it.


    The O/P has already described the cabling
    in place which is more than enough for a *simple* serial transmission.

    And numerous people commented that it was too bad that the cable
    was put into the ground before the communication protocol was
    considered. And that twisted pair would have been better.


    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.

    Just like an ESP8266. In fact - you (can) use the Arduino IDE and the
    Arduino c++ to program it. Cheap and easy as well + wifi capabilities


    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
    many sensors speak RS485 out-of-the-box. More HATs or converters?


    Finally, such a system is reliable, maintainable, and extensible.

    Indeed it is. But is the only - or the best - option here?





    --
    Björn
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Fri Sep 10 12:13:20 2021
    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....

    --
    "I am inclined to tell the truth and dislike people who lie consistently.
    This makes me unfit for the company of people of a Left persuasion, and
    all women"
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Folderol on Fri Sep 10 12:21:15 2021
    On 10/09/2021 09:54, Folderol wrote:
    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 transm
    Agreed

    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
    the data line. Unless obe wire doies NOT work there is no need top
    complicate things bey adding local power and electronics


    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.

    I mentioned a pi zero W because a lot more work is already done for you,
    it dies wifi and you can get a 1 wire hat

    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.

    ideally yes, but one wire at 16.7kbs SHOULD work for nearly all, if not
    all, the sensors

    Finally, such a system is reliable, maintainable, and extensible.

    But its over complicated
    And requires remote power


    --
    “But what a weak barrier is truth when it stands in the way of an hypothesis!â€

    Mary Wollstonecraft
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@3:770/3 to All on Fri Sep 10 14:47:28 2021
    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.

    --
    Björn
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to b.f.lundin@gmail.com on Fri Sep 10 14:53:55 2021
    On Fri, 10 Sep 2021 14:47:28 +0200
    Björn Lundin <b.f.lundin@gmail.com> wrote:

    wifi or serial or bongo drums

    Time for a new RFC - IP over Bongo Drums, should be easier than
    rfc 1149 (which has actually been implemented, ping time was rather long).

    --
    Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun
    The computer obeys and wins. | licences available see
    You lose and Bill collects. | http://www.sohara.org/
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Fri Sep 10 14:41:41 2021
    On 10/09/2021 13:47, Björn Lundin wrote:
    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.

    I was more trying to indicate that wifi reception is not just location sensitive but time sensitive, what works today may not work tomorrow


    --
    "When one man dies it's a tragedy. When thousands die it's statistics."

    Josef Stalin
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Theo on Fri Sep 10 15:51:12 2021
    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.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to The Natural Philosopher on Fri Sep 10 16:33:21 2021
    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to A. Dumas on Fri Sep 10 17:13:36 2021
    On 10/09/2021 16:51, A. Dumas wrote:
    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.




    It is a reasonably high frequency 16.7kbps serial. 5V peak to peak. I
    think it has a good chance of working quite well



    --
    It’s easier to fool people than to convince them that they have been fooled. Mark Twain
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Theo on Fri Sep 10 17:10:54 2021
    On 10/09/2021 16:33, Theo wrote:
    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:

    Not sure that was me, but i'll take the credit :-)

    "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."

    well I think at 16.7kbps twisted or not twisted won't make much difference.

    That's high audio and ultrasonic and experience suggests that hum pickup
    will dominate. I reckon it should be OK - but the thing is that the
    transducers are uber cheap and its very easy to just try it out at no
    huge expenbse



    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.

    I wouldn't think it will make a huge difference twisted or not - twisted reduces noise from adjacent cables in a bundle, but here there are no
    adjacent cables



    Theo



    --
    "Women actually are capable of being far more than the feminists will
    let them."
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Theo on Fri Sep 10 23:32:17 2021
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    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."

    Well I posted that link actually, and since also referred the OP to
    this document describing usage of three cable types:

    http://midondesign.com/Documents/1-WireApplicationGuide103.pdf
    (page 10) Suggest CAT5 cabling for distances over 100ft.

    I think that's probably conservative though, the only issue
    potentially being electrical noise from the motors. But I'm just
    repeating myself now so I think I'll leave this thread until the
    OP actually decides to try something.

    --
    __ __
    #_ < |\| |< _#
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to All on Tue Sep 14 11:46:53 2021
    On 09/09/2021 13:10, Soviet_Mario wrote:
    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:
    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 ?

    They will run on anything that has more than 1 wire!

    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.

    Should be fine, I've used 1-wire ds18b20 sensors from a Raspberry Pi out
    to 20 meters using 3 cores of flat 4 core wiring for LED light strips,
    and out to about 40 meters using some old 0.75mm2 3-core mains flex.

    ---druck
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)