• UART connection between ATSAMD20 and ATtiny4313

    From pozz@pozzugno@gmail.com to comp.arch.embedded on Wed Apr 26 16:56:55 2023
    From Newsgroup: comp.arch.embedded

    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the
    SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will
    use an external 32.768kHz crystal (that is multiplied by internal PLL to
    reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to
    the internal oscillator of ATtiny4313 that hasn't a good accuracy over temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the
    range 0-80°C.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Wed Apr 26 17:57:21 2023
    From Newsgroup: comp.arch.embedded

    On 26/04/2023 16:56, pozz wrote:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the
    SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will
    use an external 32.768kHz crystal (that is multiplied by internal PLL to reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to
    the internal oscillator of ATtiny4313 that hasn't a good accuracy over temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the range 0-80°C.

    The rule of thumb is a maximum of 5% total mismatch in baud rates
    between the two sides. One side has a crystal and PLL, so it will be
    quite close - that means you can have most of the error margin on the
    other side. If the internal oscillator is within 2%, you should be
    fine. If it is 5% or more, you will want to do some automatic
    measurement of the rate.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Wed Apr 26 09:26:06 2023
    From Newsgroup: comp.arch.embedded

    On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the
    SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will
    use an external 32.768kHz crystal (that is multiplied by internal PLL to reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to
    the internal oscillator of ATtiny4313 that hasn't a good accuracy over temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the range 0-80°C.
    I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them.
    You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit?
    --
    Rick C.
    - Get 1,000 miles of free Supercharging
    - Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Wed Apr 26 22:40:29 2023
    From Newsgroup: comp.arch.embedded

    Il 26/04/2023 17:57, David Brown ha scritto:
    On 26/04/2023 16:56, pozz wrote:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by
    the SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will
    use an external 32.768kHz crystal (that is multiplied by internal PLL
    to reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related
    to the internal oscillator of ATtiny4313 that hasn't a good accuracy
    over temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in
    the range 0-80°C.

    The rule of thumb is a maximum of 5% total mismatch in baud rates
    between the two sides.  One side has a crystal and PLL, so it will be
    quite close - that means you can have most of the error margin on the
    other side.  If the internal oscillator is within 2%, you should be
    fine.  If it is 5% or more, you will want to do some automatic
    measurement of the rate.


    ATtiny4313 datasheet[1] says the internal oscillator is factory
    calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature.
    This accuracy can be reduced to +/-2% at a fixed voltage and a fixed temperature with a user calibration.

    I could calibrate for a fixed voltage (3.3V), but I can't fix a
    temperature, because it can vary in the real application.

    I tried to heat the ATtiny4313 with a heat gun and the communication
    between SAM and tiny didn't stopped, but I know this isn't an exaustive
    test.


    [1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Wed Apr 26 22:44:13 2023
    From Newsgroup: comp.arch.embedded

    Il 26/04/2023 18:26, Rick C ha scritto:
    On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the
    SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will
    use an external 32.768kHz crystal (that is multiplied by internal PLL to
    reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to
    the internal oscillator of ATtiny4313 that hasn't a good accuracy over
    temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the
    range 0-80°C.

    I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them.

    ATtiny4313 datasheet[1] says the internal oscillator is factory
    calibrated with an accuracy of ±10% at Vcc=3V and 25°C temperature. This accuracy can be reduced to ±2% at a fixed voltage and a fixed
    temperature with a user calibration.


    You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit?


    I will use the interal UART peripheral of ATtiny4313. I can't add too
    much code, the Flash memory is almost full. I wanted to know if the
    figures shown on the datasheet guarantee good communication between the
    the MCUs. It seems this isn't the case.


    [1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Grant Edwards@invalid@invalid.invalid to comp.arch.embedded on Wed Apr 26 21:00:16 2023
    From Newsgroup: comp.arch.embedded

    On 2023-04-26, pozz <pozzugno@gmail.com> wrote:

    ATtiny4313 datasheet[1] says the internal oscillator is factory
    calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature.

    10% total error (combination of both ends) is pretty much right at the
    limit according to the usual rule of thumb for UART receivers that
    sync only on the start bit. IIRC, there used to be UART receivers that
    would sync on every edge within the data "word" as well, but I don't
    think that was ever very common -- and to take advantage of it, you
    had to make sure your data had edges. :)

    Can you spare a line for a clock and go synchronous? (Or are they
    really UARTs and not USARTs?).

    This accuracy can be reduced to +/-2% at a fixed voltage and a fixed temperature with a user calibration.

    2% is no problem at all. With a crystal on the other end, you should
    be able to easily tolerate +/-5%. The requirement for a fixed
    temperature, OTOH, is usually a problem.

    I could calibrate for a fixed voltage (3.3V), but I can't fix a
    temperature, because it can vary in the real application.

    Does the ATtiny have an on-die temp sensor? If yes, you could try characterizing the oscillator over temperature at 3.3V and adjusting
    the baud rate divisor as the temperature changes. That get's expensive
    if you have to do it on every unit during production, but if the T/F
    curve is consistent enough between units, then maybe...


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Wed Apr 26 17:10:53 2023
    From Newsgroup: comp.arch.embedded

    On Wednesday, April 26, 2023 at 4:44:20 PM UTC-4, pozz wrote:
    Il 26/04/2023 18:26, Rick C ha scritto:
    On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the >> SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will
    use an external 32.768kHz crystal (that is multiplied by internal PLL to >> reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to >> the internal oscillator of ATtiny4313 that hasn't a good accuracy over
    temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the >> range 0-80°C.

    I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them.
    ATtiny4313 datasheet[1] says the internal oscillator is factory
    calibrated with an accuracy of ±10% at Vcc=3V and 25°C temperature. This accuracy can be reduced to ±2% at a fixed voltage and a fixed
    temperature with a user calibration.
    Ok, that is information. Do you have a question?
    You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit?

    I will use the interal UART peripheral of ATtiny4313. I can't add too
    much code, the Flash memory is almost full. I wanted to know if the
    figures shown on the datasheet guarantee good communication between the
    the MCUs. It seems this isn't the case.


    [1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf
    You point me to a data sheet. I am not reading the data sheet to do your work for you. I'm happy to discuss the information and offer advice and opinion. The info you provide above with the 2% stability if temperature and voltage are maintained and the clock calibrated, is not enough to know if this will work.
    When you write, "It seems this isn't the case.", what do you base this on? What is your reasoning?
    I don't think the software UART is a lot of code, but you don't need that. You need to write a routine to measure a bit time on the input to calibrate your clock to the incoming bit times. That should not be a lot of code. Translating a loop count into a bit clock setting for the UART should be a simple linear relationship, although it may involve a divide. You only need to work over a small range, so a small table lookup should be pretty close to optimal solution.
    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
    --
    Rick C.
    + Get 1,000 miles of free Supercharging
    + Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Wed Apr 26 17:20:53 2023
    From Newsgroup: comp.arch.embedded

    On Wednesday, April 26, 2023 at 5:00:22 PM UTC-4, Grant Edwards wrote:
    On 2023-04-26, pozz <pozz...@gmail.com> wrote:

    ATtiny4313 datasheet[1] says the internal oscillator is factory
    calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature.
    10% total error (combination of both ends) is pretty much right at the
    limit according to the usual rule of thumb for UART receivers that
    sync only on the start bit.
    I think you are not doing the calculation right. The limit is based on the UART trying to sample in the middle of a bit. If it gets out by a half a bit time, either way, it will sample the wrong bit. With 10 bits in the character, including start and stop bits, that puts the total error limit at about 5%. This is actually closer to 5.5% (because while it is 10 bits, it's only 9 bit times between start and stop bits), but then you need to subtract a fraction of a bit for the internal Nx clock used to sample the bit stream. So round off to 5%. That's the total error allowed, including both ends. Then there's distortion in the pulse edges. With 26 us bit times, there may be issues with asymmetric edge distortion. There has been no mention of the electrical interface.
    IIRC, there used to be UART receivers that
    would sync on every edge within the data "word" as well, but I don't
    think that was ever very common -- and to take advantage of it, you
    had to make sure your data had edges. :)

    Can you spare a line for a clock and go synchronous? (Or are they
    really UARTs and not USARTs?).
    This accuracy can be reduced to +/-2% at a fixed voltage and a fixed temperature with a user calibration.
    2% is no problem at all. With a crystal on the other end, you should
    be able to easily tolerate +/-5%. The requirement for a fixed
    temperature, OTOH, is usually a problem.
    I could calibrate for a fixed voltage (3.3V), but I can't fix a temperature, because it can vary in the real application.
    Does the ATtiny have an on-die temp sensor? If yes, you could try characterizing the oscillator over temperature at 3.3V and adjusting
    the baud rate divisor as the temperature changes. That get's expensive
    if you have to do it on every unit during production, but if the T/F
    curve is consistent enough between units, then maybe...
    Calibration, in general is expensive. But yes, a calibration curve is worse, since you need to wait for temperature to adjust.
    --
    Rick C.
    -- Get 1,000 miles of free Supercharging
    -- Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Thu Apr 27 09:17:36 2023
    From Newsgroup: comp.arch.embedded

    On 27/04/2023 02:10, Rick C wrote:

    I don't think the software UART is a lot of code, but you don't need
    that. You need to write a routine to measure a bit time on the input
    to calibrate your clock to the incoming bit times. That should not
    be a lot of code. Translating a loop count into a bit clock setting
    for the UART should be a simple linear relationship, although it may
    involve a divide. You only need to work over a small range, so a
    small table lookup should be pretty close to optimal solution.


    That's definitely one way to do it, yes.

    Have the master side send a couple of 0x00 bytes before the data, and
    use an interrupt on the Rx pin falling edge - when that comes in, count
    the time until a rising edge is seen. If that time works out to within
    10% of the nominal expected time, you are calibrated and can turn off
    the interrupt. Alternatively, send 0x55 bytes first and measure
    multiple short periods. There will be some details to work out,
    depending on the what you are sending, the type of noise you expect, how
    often you need to re-calibrate, etc. You are making a software
    equivalent to a PLL.

    There's no need for a lookup table here (unless I've got my calculations upside down!). The more cycles you count for the incoming trainer
    characters, the bigger the UART divider value you need. That means your divisions will be done with constant values, and the compiler will turn
    those into multiplies.



    An alternative is trial and error. If your clock source is ±10%, and
    you need to get within ±2%, start your UART at the nominally correct
    baud rate. If you don't receive error-free telegrams within a timeout,
    go 2% faster. Keep adding 2%, stepping from +10% to -10%, until you hit
    a baud rate that works.

    You can get even fancier here by figuring out the lowest and highest
    rates that work, then picking their average to get the best value.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Thu Apr 27 10:15:36 2023
    From Newsgroup: comp.arch.embedded

    Il 26/04/2023 23:00, Grant Edwards ha scritto:
    On 2023-04-26, pozz <pozzugno@gmail.com> wrote:

    ATtiny4313 datasheet[1] says the internal oscillator is factory
    calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature.

    10% total error (combination of both ends) is pretty much right at the
    limit according to the usual rule of thumb for UART receivers that
    sync only on the start bit. IIRC, there used to be UART receivers that
    would sync on every edge within the data "word" as well, but I don't
    think that was ever very common -- and to take advantage of it, you
    had to make sure your data had edges. :)

    Can you spare a line for a clock and go synchronous? (Or are they
    really UARTs and not USARTs?).

    No, I can't. The MCUs are not on the same board and they are really
    connected through RS485 half-duplex transceivers.


    This accuracy can be reduced to +/-2% at a fixed voltage and a fixed
    temperature with a user calibration.

    2% is no problem at all. With a crystal on the other end, you should
    be able to easily tolerate +/-5%. The requirement for a fixed
    temperature, OTOH, is usually a problem.

    I could calibrate for a fixed voltage (3.3V), but I can't fix a
    temperature, because it can vary in the real application.

    Does the ATtiny have an on-die temp sensor? If yes, you could try characterizing the oscillator over temperature at 3.3V and adjusting
    the baud rate divisor as the temperature changes. That get's expensive
    if you have to do it on every unit during production, but if the T/F
    curve is consistent enough between units, then maybe...

    Thank you for this suggestion, but I can't use this trick.


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Thu Apr 27 10:28:23 2023
    From Newsgroup: comp.arch.embedded

    Il 27/04/2023 02:10, Rick C ha scritto:
    On Wednesday, April 26, 2023 at 4:44:20 PM UTC-4, pozz wrote:
    Il 26/04/2023 18:26, Rick C ha scritto:
    On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the >>>> SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will
    use an external 32.768kHz crystal (that is multiplied by internal PLL to >>>> reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to >>>> the internal oscillator of ATtiny4313 that hasn't a good accuracy over >>>> temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the >>>> range 0-80°C.

    I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them.
    ATtiny4313 datasheet[1] says the internal oscillator is factory
    calibrated with an accuracy of ±10% at Vcc=3V and 25°C temperature. This >> accuracy can be reduced to ±2% at a fixed voltage and a fixed
    temperature with a user calibration.

    Ok, that is information. Do you have a question?


    You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit?

    I will use the interal UART peripheral of ATtiny4313. I can't add too
    much code, the Flash memory is almost full. I wanted to know if the
    figures shown on the datasheet guarantee good communication between the
    the MCUs. It seems this isn't the case.


    [1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf

    You point me to a data sheet. I am not reading the data sheet to do your work for you.

    And I don't want you do it if you don't want. The datasheet link is
    there if someone WANTS to look at it with a single click of the mouse.


    I'm happy to discuss the information and offer advice and opinion. The info you provide above with the 2% stability if temperature and voltage are maintained and the clock calibrated, is not enough to know if this will work.

    When you write, "It seems this isn't the case.", what do you base this on? What is your reasoning?

    Because internal oscillator has an accuracy of 10% and I read that UART receivers are usually able to decode the input signal with an error of
    2-5% order.

    However I tested one sample at high temperature, but the MCUs continued communicating well.


    I don't think the software UART is a lot of code, but you don't need that. You need to write a routine to measure a bit time on the input to calibrate your clock to the incoming bit times. That should not be a lot of code. Translating a loop count into a bit clock setting for the UART should be a simple linear relationship, although it may involve a divide. You only need to work over a small range, so a small table lookup should be pretty close to optimal solution.

    Ok, thanks for suggestion.


    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Andrew Smallshaw@andrews@sdf.org to comp.arch.embedded on Thu Apr 27 13:28:27 2023
    From Newsgroup: comp.arch.embedded

    On 2023-04-27, pozz <pozzugno@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates. Manchester coding
    is fine provided the clocks are within 2:1 of each other. You will
    need to bit-bang the interface though, the UART won't handle it.
    --
    Andrew Smallshaw
    andrews@sdf.org
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Thu Apr 27 09:02:41 2023
    From Newsgroup: comp.arch.embedded

    On Thursday, April 27, 2023 at 4:28:29 AM UTC-4, pozz wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:
    On Wednesday, April 26, 2023 at 4:44:20 PM UTC-4, pozz wrote:
    Il 26/04/2023 18:26, Rick C ha scritto:
    On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the >>>> SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will >>>> use an external 32.768kHz crystal (that is multiplied by internal PLL to
    reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to >>>> the internal oscillator of ATtiny4313 that hasn't a good accuracy over >>>> temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the
    range 0-80°C.

    I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them.
    ATtiny4313 datasheet[1] says the internal oscillator is factory
    calibrated with an accuracy of ±10% at Vcc=3V and 25°C temperature. This
    accuracy can be reduced to ±2% at a fixed voltage and a fixed
    temperature with a user calibration.

    Ok, that is information. Do you have a question?


    You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit?

    I will use the interal UART peripheral of ATtiny4313. I can't add too
    much code, the Flash memory is almost full. I wanted to know if the
    figures shown on the datasheet guarantee good communication between the >> the MCUs. It seems this isn't the case.


    [1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf

    You point me to a data sheet. I am not reading the data sheet to do your work for you.
    And I don't want you do it if you don't want.
    I'm glad we are in agreement. My point is you could have pointed us to any useful info in the document, or better quoted it, if there was anything you had not already quoted. I find CPU data sheets to be rather onerous to read, as they have so much data in them these days, and they don't always put timing data in the timing section, for example.
    The datasheet link is
    there if someone WANTS to look at it with a single click of the mouse.
    I'm happy to discuss the information and offer advice and opinion. The info you provide above with the 2% stability if temperature and voltage are maintained and the clock calibrated, is not enough to know if this will work.

    When you write, "It seems this isn't the case.", what do you base this on? What is your reasoning?
    Because internal oscillator has an accuracy of 10% and I read that UART receivers are usually able to decode the input signal with an error of
    2-5% order.
    The 10% was for a fixed voltage and temperature without calibration. I don't recall if you are adverse to calibration. But you do have a wide temperature range which is an issue.
    However I tested one sample at high temperature, but the MCUs continued communicating well.
    That means pretty much nothing. While testing can prove that something doesn't work, it can't prove that it does.
    Instead of simply testing pass/fail, it would have been more useful to measure the clock rate, by measuring the bit rate over temperature. Get some numbers for multiple units to see what sort of spread you get.
    I don't think the software UART is a lot of code, but you don't need that. You need to write a routine to measure a bit time on the input to calibrate your clock to the incoming bit times. That should not be a lot of code. Translating a loop count into a bit clock setting for the UART should be a simple linear relationship, although it may involve a divide. You only need to work over a small range, so a small table lookup should be pretty close to optimal solution.
    Ok, thanks for suggestion.
    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
    No, this isn't an option.
    You can't add a crystal? Then the two workable choices would appear to be calibration of each unit over temperature, or a real time calibration from the data rate of the incoming data. I can't think of any other solutions. Adding the crystal seems the simple route.
    --
    Rick C.
    -+ Get 1,000 miles of free Supercharging
    -+ Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Thu Apr 27 09:22:12 2023
    From Newsgroup: comp.arch.embedded

    On Thursday, April 27, 2023 at 9:28:33 AM UTC-4, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozz...@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.
    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates. Manchester coding
    is fine provided the clocks are within 2:1 of each other. You will
    need to bit-bang the interface though, the UART won't handle it.
    What about Manchester encoding is not RS-485? That's just an electrical interface standard, no?
    But that is a great idea... if the hardware will accommodate it. Or this can be done in the UART using a faster clock and synchronous mode. Send characters with one data bit per character, the Manchester encoded bit, x0F or xF0. It would not be terribly hard to decode the data in software.. possibly. I believe you align to the transition that is always present mid-cell, then look for the presence/absence of the other transition. The OP talked about the "small" processor being program space constrained, but again, this is not a lot of code... maybe. So maybe this will be too much. But it would solve the clocking issue. Then again, so would a crystal.
    --
    Rick C.
    +- Get 1,000 miles of free Supercharging
    +- Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Tauno Voipio@tauno.voipio@notused.fi.invalid to comp.arch.embedded on Thu Apr 27 20:18:53 2023
    From Newsgroup: comp.arch.embedded

    On 27.4.2023 16.28, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozzugno@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates. Manchester coding
    is fine provided the clocks are within 2:1 of each other. You will
    need to bit-bang the interface though, the UART won't handle it.


    I doubt that the ATTiny can handle Manchester coding at the requested
    bit rate, and it may be difficult for the SAM.

    In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
    coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
    counter units of the chip. A timer used to measure the times between
    pulse edges could be used to receive and decode the incoming data, and
    a timer running at half of the bit rate (15.625 kbit/s) could be used
    to send the data. The receiver needed to respond to interrupts at the
    incoming edge rate, and the transmitter needed to respond at the
    outgoing bit rate.
    --

    -TV

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Ulf Samuelsson@ulf.r.samuelsson@gmail.com to comp.arch.embedded on Thu Apr 27 23:03:14 2023
    From Newsgroup: comp.arch.embedded

    Den 2023-04-27 kl. 19:18, skrev Tauno Voipio:
    On 27.4.2023 16.28, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozzugno@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a
    crystal to the ATtiny. Can the SAM chip send a clock?  You can use
    an SPI port instead of a UART, or just send a clock to use for the
    bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal.  Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates.  Manchester coding
    is fine provided the clocks are within 2:1 of each other.  You will
    need to bit-bang the interface though, the UART won't handle it.


    I doubt that the ATTiny can handle Manchester coding at the requested
    bit rate, and it may be difficult for the SAM.

    Atmel implemented Manchester Coding in the SAM7 USART (My proposal)
    but the SAMD20 has a "SERCOM" module without Manchester Coding.
    I would look into the event system.


    The tiny will have to do it in S/W.
    /Ulf


    In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
    coded bus at 31.25 kbit/s. The trick was to innovatively use the timer counter units of the chip. A timer used to measure the times between
    pulse edges could be used to receive and decode the incoming data, and
    a timer running at half of the bit rate (15.625 kbit/s) could be used
    to send the data. The receiver needed to respond to interrupts at the incoming edge rate, and the transmitter needed to respond at the
    outgoing bit rate.


    The SAM4E USART supports Manchester Coding in H/W.
    The SAM4E UART does not.

    /Ulf
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Thu Apr 27 17:45:09 2023
    From Newsgroup: comp.arch.embedded

    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:
    On 27.4.2023 16.28, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozz...@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through transceivers and cabling at sensible baud rates. Manchester coding
    is fine provided the clocks are within 2:1 of each other. You will
    need to bit-bang the interface though, the UART won't handle it.
    I doubt that the ATTiny can handle Manchester coding at the requested
    bit rate, and it may be difficult for the SAM.

    In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
    coded bus at 31.25 kbit/s. The trick was to innovatively use the timer counter units of the chip. A timer used to measure the times between
    pulse edges could be used to receive and decode the incoming data, and
    a timer running at half of the bit rate (15.625 kbit/s) could be used
    to send the data. The receiver needed to respond to interrupts at the incoming edge rate, and the transmitter needed to respond at the
    outgoing bit rate.
    That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work.
    --
    Rick C.
    ++ Get 1,000 miles of free Supercharging
    ++ Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Tauno Voipio@tauno.voipio@notused.fi.invalid to comp.arch.embedded on Fri Apr 28 09:58:24 2023
    From Newsgroup: comp.arch.embedded

    On 28.4.2023 0.03, Ulf Samuelsson wrote:
    Den 2023-04-27 kl. 19:18, skrev Tauno Voipio:
    On 27.4.2023 16.28, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozzugno@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a
    crystal to the ATtiny. Can the SAM chip send a clock?  You can use >>>>> an SPI port instead of a UART, or just send a clock to use for the
    bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal.  Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates.  Manchester coding
    is fine provided the clocks are within 2:1 of each other.  You will
    need to bit-bang the interface though, the UART won't handle it.


    I doubt that the ATTiny can handle Manchester coding at the requested
    bit rate, and it may be difficult for the SAM.

    Atmel implemented Manchester Coding in the SAM7 USART (My proposal)
    but the SAMD20 has a "SERCOM" module without Manchester Coding.
    I would look into the event system.


    The tiny will have to do it in S/W.
    /Ulf


    In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
    coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
    counter units of the chip. A timer used to measure the times between
    pulse edges could be used to receive and decode the incoming data, and
    a timer running at half of the bit rate (15.625 kbit/s) could be used
    to send the data. The receiver needed to respond to interrupts at the
    incoming edge rate, and the transmitter needed to respond at the
    outgoing bit rate.


    The SAM4E USART supports Manchester Coding in H/W.
    The SAM4E UART does not.

    /Ulf


    The problem with the USART Manchester coder was in address markers
    (intentional mis-codings). It was not possible to conform with the
    markers in the IEC coding.
    --

    -TV

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Tauno Voipio@tauno.voipio@notused.fi.invalid to comp.arch.embedded on Fri Apr 28 10:00:37 2023
    From Newsgroup: comp.arch.embedded

    On 28.4.2023 3.45, Rick C wrote:
    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:
    On 27.4.2023 16.28, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozz...@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates. Manchester coding
    is fine provided the clocks are within 2:1 of each other. You will
    need to bit-bang the interface though, the UART won't handle it.
    I doubt that the ATTiny can handle Manchester coding at the requested
    bit rate, and it may be difficult for the SAM.

    In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
    coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
    counter units of the chip. A timer used to measure the times between
    pulse edges could be used to receive and decode the incoming data, and
    a timer running at half of the bit rate (15.625 kbit/s) could be used
    to send the data. The receiver needed to respond to interrupts at the
    incoming edge rate, and the transmitter needed to respond at the
    outgoing bit rate.

    That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work.


    Had to bit-bang. The USART cannot create or detect IEC H1 standard
    address marker octets.
    --

    -TV

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Fri Apr 28 00:21:01 2023
    From Newsgroup: comp.arch.embedded

    On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:
    On 28.4.2023 3.45, Rick C wrote:
    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:
    On 27.4.2023 16.28, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozz...@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates. Manchester coding
    is fine provided the clocks are within 2:1 of each other. You will
    need to bit-bang the interface though, the UART won't handle it.
    I doubt that the ATTiny can handle Manchester coding at the requested
    bit rate, and it may be difficult for the SAM.

    In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
    coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
    counter units of the chip. A timer used to measure the times between
    pulse edges could be used to receive and decode the incoming data, and
    a timer running at half of the bit rate (15.625 kbit/s) could be used
    to send the data. The receiver needed to respond to interrupts at the
    incoming edge rate, and the transmitter needed to respond at the
    outgoing bit rate.

    That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work.
    Had to bit-bang. The USART cannot create or detect IEC H1 standard
    address marker octets.
    I did a Google search and this didn't return anything useful. So I don't know for certain what an IEC H1 standard address marker octet is, but if I'm specifying the waveform, rather than relying on the hardware to do the Manchester encoding, I can't see a reason why I could not transmit any given waveform. Can you point me to something that describes these marker octets?
    --
    Rick C.
    --- Get 1,000 miles of free Supercharging
    --- Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Fri Apr 28 09:48:27 2023
    From Newsgroup: comp.arch.embedded

    On 27/04/2023 18:22, Rick C wrote:
    On Thursday, April 27, 2023 at 9:28:33 AM UTC-4, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozz...@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.
    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates. Manchester coding
    is fine provided the clocks are within 2:1 of each other. You will
    need to bit-bang the interface though, the UART won't handle it.

    What about Manchester encoding is not RS-485? That's just an electrical interface standard, no?


    Technically, you are correct. In reality, the term "RS-485" is usually
    used to mean "UART signalling on an RS-485 bus" - any other kind of
    signalling (such as Manchester encoding) would be specified explicitly.
    It's good to be technically accurate, but also good to consider less
    accurate common usage of terms.

    But that is a great idea... if the hardware will accommodate it. Or
    this can be done in the UART using a faster clock and synchronous
    mode. Send characters with one data bit per character, the
    Manchester encoded bit, x0F or xF0. It would not be terribly hard to
    decode the data in software.. possibly. I believe you align to the transition that is always present mid-cell, then look for the presence/absence of the other transition. The OP talked about the
    "small" processor being program space constrained, but again, this is
    not a lot of code... maybe. So maybe this will be too much. But it
    would solve the clocking issue. Then again, so would a crystal.


    Not all microcontroller UARTs have synchronous modes. Receiving or
    sending Manchester encoded data with a UART is fiddly because of the
    start and stop bits of UART, so it is often done by bit-banging.
    Whether or not that suits the OP, only he can say.


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Tauno Voipio@tauno.voipio@notused.fi.invalid to comp.arch.embedded on Fri Apr 28 11:43:04 2023
    From Newsgroup: comp.arch.embedded

    On 28.4.2023 10.21, Rick C wrote:
    On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:
    On 28.4.2023 3.45, Rick C wrote:
    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:
    On 27.4.2023 16.28, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozz...@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates. Manchester coding
    is fine provided the clocks are within 2:1 of each other. You will
    need to bit-bang the interface though, the UART won't handle it.
    I doubt that the ATTiny can handle Manchester coding at the requested
    bit rate, and it may be difficult for the SAM.

    In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester >>>> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer >>>> counter units of the chip. A timer used to measure the times between
    pulse edges could be used to receive and decode the incoming data, and >>>> a timer running at half of the bit rate (15.625 kbit/s) could be used
    to send the data. The receiver needed to respond to interrupts at the
    incoming edge rate, and the transmitter needed to respond at the
    outgoing bit rate.

    That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work.
    Had to bit-bang. The USART cannot create or detect IEC H1 standard
    address marker octets.

    I did a Google search and this didn't return anything useful. So I don't know for certain what an IEC H1 standard address marker octet is, but if I'm specifying the waveform, rather than relying on the hardware to do the Manchester encoding, I can't see a reason why I could not transmit any given waveform. Can you point me to something that describes these marker octets?

    The H1 bus is an industrial fieldbus and technical information about
    it has been notoriously difficult to access.

    The Manchester coding in the H1 bus is sent as current variations,
    which are converted into voltage variations for receiving.

    I'll show the more positive voltage with a plus sign and the less
    positive voltage with a minus sign.

    A state pair takes one bit time (32 us) with the change at the middle.

    A data bit of '1' is sent as +-
    A data bit of '0' is sent as -+

    There are two intentional miscodings for delimiters:

    A coding N+ is sent as ++
    A coding N- is sent as --

    A frame starts with a preamble of alternating 0's and 1's:

    1 0 1 0 1 0 1 0 1 0

    After preamble a start delimiter is sent:

    1 N+ N- 1 0 N- N+ 0

    The packet content follows, with most significant bit first.

    After last data octet an end delimiter is sent:

    1 N+ N- N+ N- 1 0 1

    After the packet the transmitter is switched off, so the line
    will stay halfway between the + and - states.

    The processor chip Manchester coders could not be twisted to
    handle the start end end delimiters correctly.
    --

    -TV



    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Fri Apr 28 01:55:45 2023
    From Newsgroup: comp.arch.embedded

    On Friday, April 28, 2023 at 3:48:32 AM UTC-4, David Brown wrote:
    On 27/04/2023 18:22, Rick C wrote:
    On Thursday, April 27, 2023 at 9:28:33 AM UTC-4, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozz...@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.
    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates. Manchester coding
    is fine provided the clocks are within 2:1 of each other. You will
    need to bit-bang the interface though, the UART won't handle it.

    What about Manchester encoding is not RS-485? That's just an electrical interface standard, no?

    Technically, you are correct. In reality, the term "RS-485" is usually
    used to mean "UART signalling on an RS-485 bus" - any other kind of signalling (such as Manchester encoding) would be specified explicitly.
    It's good to be technically accurate, but also good to consider less accurate common usage of terms.
    Not technically, actually. "Wouldn't be true RS485" is a very clear statement, which happens to also be wrong, no matter how hands are waved.
    But that is a great idea... if the hardware will accommodate it. Or
    this can be done in the UART using a faster clock and synchronous
    mode. Send characters with one data bit per character, the
    Manchester encoded bit, x0F or xF0. It would not be terribly hard to decode the data in software.. possibly. I believe you align to the transition that is always present mid-cell, then look for the presence/absence of the other transition. The OP talked about the
    "small" processor being program space constrained, but again, this is
    not a lot of code... maybe. So maybe this will be too much. But it
    would solve the clocking issue. Then again, so would a crystal.

    Not all microcontroller UARTs have synchronous modes.
    I never said anything different.
    Receiving or
    sending Manchester encoded data with a UART is fiddly because of the
    start and stop bits of UART, so it is often done by bit-banging.
    Whether or not that suits the OP, only he can say.
    It is simply not practical to send Manchester encoding with a UART... but Manchester is not the only encoding scheme that embeds a clock. Or you can roll your own. The point is, clock encoding with the data is a viable method of overcoming the lack of precision in the clock rate, which does not require bit banging an I/O pin. The encoding scheme of IRIG is a real possibility. The data bits are PWM encoded, with three values; 0.2, 0.5 and 0.8 widths for 0, 1 and a sync marker. This would fit a UART very nicely. With a distinction of symbols of 0.3 bit times, it can tolerate a lot more clock error than a typical async data stream with a start and stop bit on each character. It would also be pretty easy to decode. Align to the rising edge, and count the bits in the received data to find the falling edge. 0.1, 0.2 and 0.3 are all a zero bit. 0.4, 0.5 and 0.6 are all one bits. 0.7, 0.8 and 0.9 are all sync markers. To prevent the UART from missing anything important, set it for 7 data bits and no parity on receive. Then it always stops one bit early. Then if the timing is off by 10%, you still don't lose any data. This can be better than using a USART, actually. It does the alignment in the hardware, making the decoding simpler. It also includes a sync marker.
    Yeah, I think this is a much better scheme than Manchester encoding.
    --
    Rick C.
    --+ Get 1,000 miles of free Supercharging
    --+ Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Ulf Samuelsson@ulf.r.samuelsson@gmail.com to comp.arch.embedded on Fri Apr 28 11:10:29 2023
    From Newsgroup: comp.arch.embedded

    Den 2023-04-28 kl. 10:43, skrev Tauno Voipio:
    On 28.4.2023 10.21, Rick C wrote:
    On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:
    On 28.4.2023 3.45, Rick C wrote:
    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote: >>>>> On 27.4.2023 16.28, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozz...@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a >>>>>>>> crystal to the ATtiny. Can the SAM chip send a clock? You can >>>>>>>> use an SPI port instead of a UART, or just send a clock to use >>>>>>>> for the bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates. Manchester coding >>>>>> is fine provided the clocks are within 2:1 of each other. You will >>>>>> need to bit-bang the interface though, the UART won't handle it.
    I doubt that the ATTiny can handle Manchester coding at the requested >>>>> bit rate, and it may be difficult for the SAM.

    In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester >>>>> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer >>>>> counter units of the chip. A timer used to measure the times between >>>>> pulse edges could be used to receive and decode the incoming data, and >>>>> a timer running at half of the bit rate (15.625 kbit/s) could be used >>>>> to send the data. The receiver needed to respond to interrupts at the >>>>> incoming edge rate, and the transmitter needed to respond at the
    outgoing bit rate.

    That's if the entire job is handled in software, perhaps. The USART
    can be used to send the bits as characters at the transmitter. A
    USART can be used to handle the reception with software seeking
    edges. I don't think that would be a huge burden at 38.4 kbps. But
    then, I'm more used to FPGA work.
    Had to bit-bang. The USART cannot create or detect IEC H1 standard
    address marker octets.

    I did a Google search and this didn't return anything useful.  So I
    don't know for certain what an IEC H1 standard address marker octet
    is, but if I'm specifying the waveform, rather than relying on the
    hardware to do the Manchester encoding, I can't see a reason why I
    could not transmit any given waveform.  Can you point me to something
    that describes these marker octets?

    The H1 bus is an industrial fieldbus and technical information about
    it has been notoriously difficult to access.

    The Manchester coding in the H1 bus is sent as current variations,
    which are converted into voltage variations for receiving.

    I'll show the more positive voltage with a plus sign and the less
    positive voltage with a minus sign.

    A state pair takes one bit time (32 us) with the change at the middle.

    A data bit of '1' is sent as +-
    A data bit of '0' is sent as -+

    There are two intentional miscodings for delimiters:

    A coding N+ is sent as ++
    A coding N- is sent as --

    A frame starts with a preamble of alternating 0's and 1's:

    1 0 1 0 1 0 1 0 1 0

    After preamble a start delimiter is sent:

    1 N+ N- 1 0 N- N+ 0

    The packet content follows, with most significant bit first.

    After last data octet an end delimiter is sent:

    1 N+ N- N+ N- 1 0 1

    After the packet the transmitter is switched off, so the line
    will stay halfway between the + and - states.

    The processor chip Manchester coders could not be twisted to
    handle the start end end delimiters correctly.


    If the bus speed is known, this packet seems overkill.
    It can be used to detect the BAUD rate.

    The Atmel USART is designed to use a 9-bit mode for packet data, with
    the 9th bit set for addresses.

    /Ulf.


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Fri Apr 28 02:14:44 2023
    From Newsgroup: comp.arch.embedded

    On Friday, April 28, 2023 at 4:43:13 AM UTC-4, Tauno Voipio wrote:
    On 28.4.2023 10.21, Rick C wrote:
    On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:
    On 28.4.2023 3.45, Rick C wrote:
    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote: >>>> On 27.4.2023 16.28, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozz...@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates. Manchester coding >>>>> is fine provided the clocks are within 2:1 of each other. You will >>>>> need to bit-bang the interface though, the UART won't handle it.
    I doubt that the ATTiny can handle Manchester coding at the requested >>>> bit rate, and it may be difficult for the SAM.

    In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester >>>> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer >>>> counter units of the chip. A timer used to measure the times between >>>> pulse edges could be used to receive and decode the incoming data, and >>>> a timer running at half of the bit rate (15.625 kbit/s) could be used >>>> to send the data. The receiver needed to respond to interrupts at the >>>> incoming edge rate, and the transmitter needed to respond at the
    outgoing bit rate.

    That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work.
    Had to bit-bang. The USART cannot create or detect IEC H1 standard
    address marker octets.

    I did a Google search and this didn't return anything useful. So I don't know for certain what an IEC H1 standard address marker octet is, but if I'm specifying the waveform, rather than relying on the hardware to do the Manchester encoding, I can't see a reason why I could not transmit any given waveform. Can you point me to something that describes these marker octets?
    The H1 bus is an industrial fieldbus and technical information about
    it has been notoriously difficult to access.

    The Manchester coding in the H1 bus is sent as current variations,
    which are converted into voltage variations for receiving.

    I'll show the more positive voltage with a plus sign and the less
    positive voltage with a minus sign.

    A state pair takes one bit time (32 us) with the change at the middle.

    A data bit of '1' is sent as +-
    A data bit of '0' is sent as -+

    There are two intentional miscodings for delimiters:

    A coding N+ is sent as ++
    A coding N- is sent as --

    A frame starts with a preamble of alternating 0's and 1's:

    1 0 1 0 1 0 1 0 1 0

    After preamble a start delimiter is sent:

    1 N+ N- 1 0 N- N+ 0

    The packet content follows, with most significant bit first.

    After last data octet an end delimiter is sent:

    1 N+ N- N+ N- 1 0 1

    After the packet the transmitter is switched off, so the line
    will stay halfway between the + and - states.

    The processor chip Manchester coders could not be twisted to
    handle the start end end delimiters correctly.
    Yes, my point is you can run the USART at a higher rate and send data as x0F, xF0, x00 or xFF. You can use the hardware without a hardware Manchester encoder.
    Actually, I think Manchester encoding is inferior to the scheme they use in the IRIG signal (also the WWVB time broadcast). I don't know if that PWM scheme has a particular name, but it is very robust and can be implemented with a UART, so no USART required. The UART aligns to the start of the bit frame, so less work in the software. It becomes a matter of recognizing which of the 7 bit patterns are received. You really only need to look at two bit positions to distinguish the three values.
    --
    Rick C.
    -+- Get 1,000 miles of free Supercharging
    -+- Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Fri Apr 28 02:19:18 2023
    From Newsgroup: comp.arch.embedded

    On Friday, April 28, 2023 at 5:14:48 AM UTC-4, Rick C wrote:
    On Friday, April 28, 2023 at 4:43:13 AM UTC-4, Tauno Voipio wrote:
    On 28.4.2023 10.21, Rick C wrote:
    On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:
    On 28.4.2023 3.45, Rick C wrote:
    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote: >>>> On 27.4.2023 16.28, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozz...@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through >>>>> transceivers and cabling at sensible baud rates. Manchester coding >>>>> is fine provided the clocks are within 2:1 of each other. You will >>>>> need to bit-bang the interface though, the UART won't handle it. >>>> I doubt that the ATTiny can handle Manchester coding at the requested >>>> bit rate, and it may be difficult for the SAM.

    In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
    coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
    counter units of the chip. A timer used to measure the times between >>>> pulse edges could be used to receive and decode the incoming data, and
    a timer running at half of the bit rate (15.625 kbit/s) could be used >>>> to send the data. The receiver needed to respond to interrupts at the >>>> incoming edge rate, and the transmitter needed to respond at the
    outgoing bit rate.

    That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work.
    Had to bit-bang. The USART cannot create or detect IEC H1 standard
    address marker octets.

    I did a Google search and this didn't return anything useful. So I don't know for certain what an IEC H1 standard address marker octet is, but if I'm specifying the waveform, rather than relying on the hardware to do the Manchester encoding, I can't see a reason why I could not transmit any given waveform. Can you point me to something that describes these marker octets?
    The H1 bus is an industrial fieldbus and technical information about
    it has been notoriously difficult to access.

    The Manchester coding in the H1 bus is sent as current variations,
    which are converted into voltage variations for receiving.

    I'll show the more positive voltage with a plus sign and the less
    positive voltage with a minus sign.

    A state pair takes one bit time (32 us) with the change at the middle.

    A data bit of '1' is sent as +-
    A data bit of '0' is sent as -+

    There are two intentional miscodings for delimiters:

    A coding N+ is sent as ++
    A coding N- is sent as --

    A frame starts with a preamble of alternating 0's and 1's:

    1 0 1 0 1 0 1 0 1 0

    After preamble a start delimiter is sent:

    1 N+ N- 1 0 N- N+ 0

    The packet content follows, with most significant bit first.

    After last data octet an end delimiter is sent:

    1 N+ N- N+ N- 1 0 1

    After the packet the transmitter is switched off, so the line
    will stay halfway between the + and - states.

    The processor chip Manchester coders could not be twisted to
    handle the start end end delimiters correctly.
    Yes, my point is you can run the USART at a higher rate and send data as x0F, xF0, x00 or xFF. You can use the hardware without a hardware Manchester encoder.

    Actually, I think Manchester encoding is inferior to the scheme they use in the IRIG signal (also the WWVB time broadcast). I don't know if that PWM scheme has a particular name, but it is very robust and can be implemented with a UART, so no USART required. The UART aligns to the start of the bit frame, so less work in the software. It becomes a matter of recognizing which of the 7 bit patterns are received. You really only need to look at two bit positions to distinguish the three values.
    Sorry, two points to distinguish the three values encoded in the eight possible received bit patterns using a 7 bit character.
    --
    Rick C.
    -++ Get 1,000 miles of free Supercharging
    -++ Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Fri Apr 28 14:51:26 2023
    From Newsgroup: comp.arch.embedded

    On 28/04/2023 02:45, Rick C wrote:
    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:

    In 2016, I made a processor unit using AT91SAM4E for IEC H1
    Manchester coded bus at 31.25 kbit/s. The trick was to innovatively
    use the timer counter units of the chip. A timer used to measure
    the times between pulse edges could be used to receive and decode
    the incoming data, and a timer running at half of the bit rate
    (15.625 kbit/s) could be used to send the data. The receiver needed
    to respond to interrupts at the incoming edge rate, and the
    transmitter needed to respond at the outgoing bit rate.

    That's if the entire job is handled in software, perhaps. The USART
    can be used to send the bits as characters at the transmitter. A
    USART can be used to handle the reception with software seeking
    edges. I don't think that would be a huge burden at 38.4 kbps. But
    then, I'm more used to FPGA work.


    You certainly /can/ do this kind of thing in software on a Tiny.
    However, it might be a challenge depending on other factors. If the
    device already has high-precision timing requirements for another task,
    doing two of them can get complicated. If you need to deal with a lot
    of noise on the lines, that too is messy.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Fri Apr 28 15:01:02 2023
    From Newsgroup: comp.arch.embedded

    On 27/04/2023 18:02, Rick C wrote:
    On Thursday, April 27, 2023 at 4:28:29 AM UTC-4, pozz wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a
    crystal to the ATtiny. Can the SAM chip send a clock? You can use
    an SPI port instead of a UART, or just send a clock to use for
    the bit rate clock in the UART?
    No, this isn't an option.

    You can't add a crystal? Then the two workable choices would appear
    to be calibration of each unit over temperature, or a real time
    calibration from the data rate of the incoming data. I can't think
    of any other solutions. Adding the crystal seems the simple route.


    Perhaps he already has the boards produced - adding a crystal is then a
    rather difficult task! Even if the design is not completed, the Tiny is
    a very small, cheap and low power family. Adding a crystal makes the
    design bigger, more expensive and uses more power - assuming there are suitable pins free for connecting a crystal. Now, a small, cheap
    crystal might be $0.50 and just a few square millimetres, but so is a
    small AVR Tiny. I don't know why the OP is using a a Tiny, but if it is
    for good technical or economic reasons, adding a crystal would work
    against it.

    Trial-and-error, as I suggested earlier, is another workable choice.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Tauno Voipio@tauno.voipio@notused.fi.invalid to comp.arch.embedded on Fri Apr 28 17:26:35 2023
    From Newsgroup: comp.arch.embedded

    On 28.4.2023 12.10, Ulf Samuelsson wrote:
    Den 2023-04-28 kl. 10:43, skrev Tauno Voipio:
    On 28.4.2023 10.21, Rick C wrote:
    On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:
    On 28.4.2023 3.45, Rick C wrote:
    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote: >>>>>> On 27.4.2023 16.28, Andrew Smallshaw wrote:
    On 2023-04-27, pozz <pozz...@gmail.com> wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a >>>>>>>>> crystal to the ATtiny. Can the SAM chip send a clock? You can >>>>>>>>> use an SPI port instead of a UART, or just send a clock to use >>>>>>>>> for the bit rate clock in the UART?

    No, this isn't an option.

    The other option would be to adopt a Manchester-encoded (self
    clocking) signal. Wouldn't be true RS485 but would pass through
    transceivers and cabling at sensible baud rates. Manchester coding >>>>>>> is fine provided the clocks are within 2:1 of each other. You will >>>>>>> need to bit-bang the interface though, the UART won't handle it.
    I doubt that the ATTiny can handle Manchester coding at the requested >>>>>> bit rate, and it may be difficult for the SAM.

    In 2016, I made a processor unit using AT91SAM4E for IEC H1
    Manchester
    coded bus at 31.25 kbit/s. The trick was to innovatively use the
    timer
    counter units of the chip. A timer used to measure the times between >>>>>> pulse edges could be used to receive and decode the incoming data, >>>>>> and
    a timer running at half of the bit rate (15.625 kbit/s) could be used >>>>>> to send the data. The receiver needed to respond to interrupts at the >>>>>> incoming edge rate, and the transmitter needed to respond at the
    outgoing bit rate.

    That's if the entire job is handled in software, perhaps. The USART >>>>> can be used to send the bits as characters at the transmitter. A
    USART can be used to handle the reception with software seeking
    edges. I don't think that would be a huge burden at 38.4 kbps. But
    then, I'm more used to FPGA work.
    Had to bit-bang. The USART cannot create or detect IEC H1 standard
    address marker octets.

    I did a Google search and this didn't return anything useful.  So I
    don't know for certain what an IEC H1 standard address marker octet
    is, but if I'm specifying the waveform, rather than relying on the
    hardware to do the Manchester encoding, I can't see a reason why I
    could not transmit any given waveform.  Can you point me to something
    that describes these marker octets?

    The H1 bus is an industrial fieldbus and technical information about
    it has been notoriously difficult to access.

    The Manchester coding in the H1 bus is sent as current variations,
    which are converted into voltage variations for receiving.

    I'll show the more positive voltage with a plus sign and the less
    positive voltage with a minus sign.

    A state pair takes one bit time (32 us) with the change at the middle.

    A data bit of '1' is sent as +-
    A data bit of '0' is sent as -+

    There are two intentional miscodings for delimiters:

    A coding N+ is sent as ++
    A coding N- is sent as --

    A frame starts with a preamble of alternating 0's and 1's:

    1 0 1 0 1 0 1 0 1 0

    After preamble a start delimiter is sent:

    1 N+ N- 1 0 N- N+ 0

    The packet content follows, with most significant bit first.

    After last data octet an end delimiter is sent:

    1 N+ N- N+ N- 1 0 1

    After the packet the transmitter is switched off, so the line
    will stay halfway between the + and - states.

    The processor chip Manchester coders could not be twisted to
    handle the start end end delimiters correctly.


    If the bus speed is known, this packet seems overkill.
    It can be used to detect the BAUD rate.

    The Atmel USART is designed to use a 9-bit mode for packet data, with
    the 9th bit set for addresses.

    /Ulf.




    The packet structure and coding is set in the standard. An USART cannot
    create the bit patterns, even with fictive data, as there are fixed
    start and stop bit patterns.
    --

    -TV


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Fri Apr 28 16:41:37 2023
    From Newsgroup: comp.arch.embedded

    On Friday, April 28, 2023 at 8:51:33 AM UTC-4, David Brown wrote:
    On 28/04/2023 02:45, Rick C wrote:
    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:

    In 2016, I made a processor unit using AT91SAM4E for IEC H1
    Manchester coded bus at 31.25 kbit/s. The trick was to innovatively
    use the timer counter units of the chip. A timer used to measure
    the times between pulse edges could be used to receive and decode
    the incoming data, and a timer running at half of the bit rate
    (15.625 kbit/s) could be used to send the data. The receiver needed
    to respond to interrupts at the incoming edge rate, and the
    transmitter needed to respond at the outgoing bit rate.

    That's if the entire job is handled in software, perhaps. The USART
    can be used to send the bits as characters at the transmitter. A
    USART can be used to handle the reception with software seeking
    edges. I don't think that would be a huge burden at 38.4 kbps. But
    then, I'm more used to FPGA work.

    You certainly /can/ do this kind of thing in software on a Tiny.
    However, it might be a challenge depending on other factors. If the
    device already has high-precision timing requirements for another task, doing two of them can get complicated. If you need to deal with a lot
    of noise on the lines, that too is messy.
    I don't think you understand the issues. If there is a lot of noise, the project is dead in the water regardless. Fix your noise problems.
    This does not impose "high-precision timing requirements" on the CPU. The only requirements are to handle the data without dropping. It's NOT bit banging, so there is lots of time to handle the data.
    If the CPU is overloaded, then you picked the wrong CPU. Get a faster one. Why are you bringing in all this silliness? It's almost as if you've never done design work.
    --
    Rick C.
    +-- Get 1,000 miles of free Supercharging
    +-- Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Fri Apr 28 16:44:01 2023
    From Newsgroup: comp.arch.embedded

    On Friday, April 28, 2023 at 9:01:09 AM UTC-4, David Brown wrote:
    On 27/04/2023 18:02, Rick C wrote:
    On Thursday, April 27, 2023 at 4:28:29 AM UTC-4, pozz wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a
    crystal to the ATtiny. Can the SAM chip send a clock? You can use
    an SPI port instead of a UART, or just send a clock to use for
    the bit rate clock in the UART?
    No, this isn't an option.

    You can't add a crystal? Then the two workable choices would appear
    to be calibration of each unit over temperature, or a real time calibration from the data rate of the incoming data. I can't think
    of any other solutions. Adding the crystal seems the simple route.

    Perhaps he already has the boards produced - adding a crystal is then a rather difficult task! Even if the design is not completed, the Tiny is
    a very small, cheap and low power family. Adding a crystal makes the
    design bigger, more expensive and uses more power - assuming there are suitable pins free for connecting a crystal. Now, a small, cheap
    crystal might be $0.50 and just a few square millimetres, but so is a
    small AVR Tiny. I don't know why the OP is using a a Tiny, but if it is
    for good technical or economic reasons, adding a crystal would work
    against it.

    Trial-and-error, as I suggested earlier, is another workable choice.
    Yes, trial and error. I believe that's the design process recommended by NASA.
    WTF are you talking about? If he's designed the board without considering the requirements, that's a failure of the first order. If someone imposed new requirements on the design, that's a perfect justification to respin the board.
    Once again, not rocket science.
    --
    Rick C.
    +-+ Get 1,000 miles of free Supercharging
    +-+ Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Sat Apr 29 17:59:53 2023
    From Newsgroup: comp.arch.embedded

    On 29/04/2023 01:44, Rick C wrote:
    On Friday, April 28, 2023 at 9:01:09 AM UTC-4, David Brown wrote:
    On 27/04/2023 18:02, Rick C wrote:
    On Thursday, April 27, 2023 at 4:28:29 AM UTC-4, pozz wrote:
    Il 27/04/2023 02:10, Rick C ha scritto:

    I don't see where you have a choice, unless you want to add a
    crystal to the ATtiny. Can the SAM chip send a clock? You can use
    an SPI port instead of a UART, or just send a clock to use for
    the bit rate clock in the UART?
    No, this isn't an option.

    You can't add a crystal? Then the two workable choices would appear
    to be calibration of each unit over temperature, or a real time
    calibration from the data rate of the incoming data. I can't think
    of any other solutions. Adding the crystal seems the simple route.

    Perhaps he already has the boards produced - adding a crystal is then a
    rather difficult task! Even if the design is not completed, the Tiny is
    a very small, cheap and low power family. Adding a crystal makes the
    design bigger, more expensive and uses more power - assuming there are
    suitable pins free for connecting a crystal. Now, a small, cheap
    crystal might be $0.50 and just a few square millimetres, but so is a
    small AVR Tiny. I don't know why the OP is using a a Tiny, but if it is
    for good technical or economic reasons, adding a crystal would work
    against it.

    Trial-and-error, as I suggested earlier, is another workable choice.

    Yes, trial and error. I believe that's the design process recommended by NASA.


    Feel free to try /reading/ posts before making comments about them that
    show you up your ignorance.

    WTF are you talking about? If he's designed the board without considering the requirements, that's a failure of the first order. If someone imposed new requirements on the design, that's a perfect justification to respin the board.

    Once again, not rocket science.


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Sat Apr 29 18:01:46 2023
    From Newsgroup: comp.arch.embedded

    On 29/04/2023 01:41, Rick C wrote:
    On Friday, April 28, 2023 at 8:51:33 AM UTC-4, David Brown wrote:
    On 28/04/2023 02:45, Rick C wrote:
    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio
    wrote:

    In 2016, I made a processor unit using AT91SAM4E for IEC H1
    Manchester coded bus at 31.25 kbit/s. The trick was to
    innovatively use the timer counter units of the chip. A timer
    used to measure the times between pulse edges could be used to
    receive and decode the incoming data, and a timer running at
    half of the bit rate (15.625 kbit/s) could be used to send the
    data. The receiver needed to respond to interrupts at the
    incoming edge rate, and the transmitter needed to respond at
    the outgoing bit rate.

    That's if the entire job is handled in software, perhaps. The
    USART can be used to send the bits as characters at the
    transmitter. A USART can be used to handle the reception with
    software seeking edges. I don't think that would be a huge burden
    at 38.4 kbps. But then, I'm more used to FPGA work.

    You certainly /can/ do this kind of thing in software on a Tiny.
    However, it might be a challenge depending on other factors. If
    the device already has high-precision timing requirements for
    another task, doing two of them can get complicated. If you need to
    deal with a lot of noise on the lines, that too is messy.


    I don't think you understand the issues. If there is a lot of noise,
    the project is dead in the water regardless. Fix your noise
    problems.

    This does not impose "high-precision timing requirements" on the CPU.
    The only requirements are to handle the data without dropping. It's
    NOT bit banging, so there is lots of time to handle the data.

    If the CPU is overloaded, then you picked the wrong CPU. Get a
    faster one.

    Why are you bringing in all this silliness? It's almost as if you've
    never done design work.


    Have you heard the saying that it is better to keep quite and be thought
    a fool, rather than opening your mouth and proving it? Do you think the
    OP would have started this discussion if "just use a better
    microcontroller" were a viable option?




    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Sun Apr 30 02:37:03 2023
    From Newsgroup: comp.arch.embedded

    On Saturday, April 29, 2023 at 12:01:52 PM UTC-4, David Brown wrote:
    On 29/04/2023 01:41, Rick C wrote:
    On Friday, April 28, 2023 at 8:51:33 AM UTC-4, David Brown wrote:
    On 28/04/2023 02:45, Rick C wrote:
    On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio
    wrote:

    In 2016, I made a processor unit using AT91SAM4E for IEC H1
    Manchester coded bus at 31.25 kbit/s. The trick was to
    innovatively use the timer counter units of the chip. A timer
    used to measure the times between pulse edges could be used to
    receive and decode the incoming data, and a timer running at
    half of the bit rate (15.625 kbit/s) could be used to send the
    data. The receiver needed to respond to interrupts at the
    incoming edge rate, and the transmitter needed to respond at
    the outgoing bit rate.

    That's if the entire job is handled in software, perhaps. The
    USART can be used to send the bits as characters at the
    transmitter. A USART can be used to handle the reception with
    software seeking edges. I don't think that would be a huge burden
    at 38.4 kbps. But then, I'm more used to FPGA work.

    You certainly /can/ do this kind of thing in software on a Tiny.
    However, it might be a challenge depending on other factors. If
    the device already has high-precision timing requirements for
    another task, doing two of them can get complicated. If you need to
    deal with a lot of noise on the lines, that too is messy.


    I don't think you understand the issues. If there is a lot of noise,
    the project is dead in the water regardless. Fix your noise
    problems.

    This does not impose "high-precision timing requirements" on the CPU.
    The only requirements are to handle the data without dropping. It's
    NOT bit banging, so there is lots of time to handle the data.

    If the CPU is overloaded, then you picked the wrong CPU. Get a
    faster one.

    Why are you bringing in all this silliness? It's almost as if you've
    never done design work.

    Have you heard the saying that it is better to keep quite and be thought
    a fool, rather than opening your mouth and proving it? Do you think the
    OP would have started this discussion if "just use a better
    microcontroller" were a viable option?
    David, that wasn't a reply to the OP, that was to your silly speculation.
    --
    Rick C.
    ++- Get 1,000 miles of free Supercharging
    ++- Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Wed May 3 18:16:43 2023
    From Newsgroup: comp.arch.embedded

    Il 26/04/2023 16:56, pozz ha scritto:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the
    SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will
    use an external 32.768kHz crystal (that is multiplied by internal PLL to reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to
    the internal oscillator of ATtiny4313 that hasn't a good accuracy over temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the range 0-80°C.

    I want to thank all the ones that spent some time to reply and give suggestions. As usual, they are valuable for me.

    I'm working on a board that is already in production. It was chosen a
    tiny for its low cost.
    The possibility to mount and use an external ceramic resonator is
    available. Moreover it has been really mounted on around 1k boards that
    are working now.

    However a few customers reported a problem in a few installations: the
    tiny blocks and only a power cycle is able to restart.

    After some tests, we found that the problem is radiated noise on the
    pins of the tiny oscillator. When power cables are near the board and
    some specific load are connected to these cables, the noise generated is capable to block the tiny.

    We tried to replace the ceramic resonator with a quartz crystal without success. We tried to strenghten the GND connection between the resonator/quartz and the single GND pin of the SOIC20, without success.

    The only change that seems effective in avoiding blocks is using the
    internal oscillator.

    This is the story.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Wed May 3 09:40:42 2023
    From Newsgroup: comp.arch.embedded

    On Wednesday, May 3, 2023 at 12:16:49 PM UTC-4, pozz wrote:
    Il 26/04/2023 16:56, pozz ha scritto:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will
    use an external 32.768kHz crystal (that is multiplied by internal PLL to reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to the internal oscillator of ATtiny4313 that hasn't a good accuracy over temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the range 0-80°C.
    I want to thank all the ones that spent some time to reply and give suggestions. As usual, they are valuable for me.

    I'm working on a board that is already in production. It was chosen a
    tiny for its low cost.
    The possibility to mount and use an external ceramic resonator is
    available. Moreover it has been really mounted on around 1k boards that
    are working now.

    However a few customers reported a problem in a few installations: the
    tiny blocks and only a power cycle is able to restart.

    After some tests, we found that the problem is radiated noise on the
    pins of the tiny oscillator. When power cables are near the board and
    some specific load are connected to these cables, the noise generated is capable to block the tiny.

    We tried to replace the ceramic resonator with a quartz crystal without success. We tried to strenghten the GND connection between the resonator/quartz and the single GND pin of the SOIC20, without success.

    The only change that seems effective in avoiding blocks is using the internal oscillator.

    This is the story.
    So I assume there is a reason why you can't route the power wires away from the ATtiny board?
    I think you have been provided with all the possibilities for how to use the internal oscillator. It rather comes down to "pick one". Are any more appealing than the others? If you tell us what you don't like about it, maybe we can help refine the solution?
    --
    Rick C.
    +++ Get 1,000 miles of free Supercharging
    +++ Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Thu May 4 10:34:19 2023
    From Newsgroup: comp.arch.embedded

    Il 03/05/2023 18:40, Rick C ha scritto:
    On Wednesday, May 3, 2023 at 12:16:49 PM UTC-4, pozz wrote:
    Il 26/04/2023 16:56, pozz ha scritto:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the
    SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will
    use an external 32.768kHz crystal (that is multiplied by internal PLL to >>> reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to
    the internal oscillator of ATtiny4313 that hasn't a good accuracy over
    temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the >>> range 0-80°C.
    I want to thank all the ones that spent some time to reply and give
    suggestions. As usual, they are valuable for me.

    I'm working on a board that is already in production. It was chosen a
    tiny for its low cost.
    The possibility to mount and use an external ceramic resonator is
    available. Moreover it has been really mounted on around 1k boards that
    are working now.

    However a few customers reported a problem in a few installations: the
    tiny blocks and only a power cycle is able to restart.

    After some tests, we found that the problem is radiated noise on the
    pins of the tiny oscillator. When power cables are near the board and
    some specific load are connected to these cables, the noise generated is
    capable to block the tiny.

    We tried to replace the ceramic resonator with a quartz crystal without
    success. We tried to strenghten the GND connection between the
    resonator/quartz and the single GND pin of the SOIC20, without success.

    The only change that seems effective in avoiding blocks is using the
    internal oscillator.

    This is the story.

    So I assume there is a reason why you can't route the power wires away from the ATtiny board?

    It depends. In some cases it is possible, in other cases it isn't. The installer isn't usually competent, so it routes cables as he wants. In
    some cases, too near my board. After some weeks or months, he complains
    the board has blocked. And he is my customer...


    I think you have been provided with all the possibilities for how to use the internal oscillator. It rather comes down to "pick one". Are any more appealing than the others? If you tell us what you don't like about it, maybe we can help refine the solution?

    At the moment we are deciding what could be the best solution.


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Thu May 4 12:31:57 2023
    From Newsgroup: comp.arch.embedded

    On 04/05/2023 10:34, pozz wrote:
    Il 03/05/2023 18:40, Rick C ha scritto:
    On Wednesday, May 3, 2023 at 12:16:49 PM UTC-4, pozz wrote:
    Il 26/04/2023 16:56, pozz ha scritto:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the >>>> SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will
    use an external 32.768kHz crystal (that is multiplied by internal
    PLL to
    reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to >>>> the internal oscillator of ATtiny4313 that hasn't a good accuracy over >>>> temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in
    the
    range 0-80°C.
    I want to thank all the ones that spent some time to reply and give
    suggestions. As usual, they are valuable for me.

    I'm working on a board that is already in production. It was chosen a
    tiny for its low cost.
    The possibility to mount and use an external ceramic resonator is
    available. Moreover it has been really mounted on around 1k boards that
    are working now.

    However a few customers reported a problem in a few installations: the
    tiny blocks and only a power cycle is able to restart.

    After some tests, we found that the problem is radiated noise on the
    pins of the tiny oscillator. When power cables are near the board and
    some specific load are connected to these cables, the noise generated is >>> capable to block the tiny.

    We tried to replace the ceramic resonator with a quartz crystal without
    success. We tried to strenghten the GND connection between the
    resonator/quartz and the single GND pin of the SOIC20, without success.

    The only change that seems effective in avoiding blocks is using the
    internal oscillator.

    This is the story.

    So I assume there is a reason why you can't route the power wires away
    from the ATtiny board?

    It depends. In some cases it is possible, in other cases it isn't. The installer isn't usually competent, so it routes cables as he wants. In
    some cases, too near my board. After some weeks or months, he complains
    the board has blocked. And he is my customer...


    I think you have been provided with all the possibilities for how to
    use the internal oscillator.  It rather comes down to "pick one".  Are
    any more appealing than the others?  If you tell us what you don't
    like about it, maybe we can help refine the solution?

    At the moment we are deciding what could be the best solution.



    Do you do EMC testing for radiation emission and susceptibility? I
    don't know what the rules and regulations are like where you are, but
    any finished product (as distinct from prototype or test systems) made
    here in Europe should be EMC certified. If radiated noise from "normal"
    power cables killed a card, that would be a failure in the certification.

    Or is it the surrounding system that is bad? Maybe there is something
    truly terrible connected to these power cables?



    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Thu May 4 06:21:14 2023
    From Newsgroup: comp.arch.embedded

    On Thursday, May 4, 2023 at 4:34:25 AM UTC-4, pozz wrote:
    Il 03/05/2023 18:40, Rick C ha scritto:
    On Wednesday, May 3, 2023 at 12:16:49 PM UTC-4, pozz wrote:
    Il 26/04/2023 16:56, pozz ha scritto:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the >>> SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will >>> use an external 32.768kHz crystal (that is multiplied by internal PLL to >>> reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to >>> the internal oscillator of ATtiny4313 that hasn't a good accuracy over >>> temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the >>> range 0-80°C.
    I want to thank all the ones that spent some time to reply and give
    suggestions. As usual, they are valuable for me.

    I'm working on a board that is already in production. It was chosen a
    tiny for its low cost.
    The possibility to mount and use an external ceramic resonator is
    available. Moreover it has been really mounted on around 1k boards that >> are working now.

    However a few customers reported a problem in a few installations: the
    tiny blocks and only a power cycle is able to restart.

    After some tests, we found that the problem is radiated noise on the
    pins of the tiny oscillator. When power cables are near the board and
    some specific load are connected to these cables, the noise generated is >> capable to block the tiny.

    We tried to replace the ceramic resonator with a quartz crystal without >> success. We tried to strenghten the GND connection between the
    resonator/quartz and the single GND pin of the SOIC20, without success. >>
    The only change that seems effective in avoiding blocks is using the
    internal oscillator.

    This is the story.

    So I assume there is a reason why you can't route the power wires away from the ATtiny board?
    It depends. In some cases it is possible, in other cases it isn't. The installer isn't usually competent, so it routes cables as he wants. In
    some cases, too near my board. After some weeks or months, he complains
    the board has blocked. And he is my customer...
    I think you have been provided with all the possibilities for how to use the internal oscillator. It rather comes down to "pick one". Are any more appealing than the others? If you tell us what you don't like about it, maybe we can help refine the solution?
    At the moment we are deciding what could be the best solution.
    Perhaps you can add an enclosure to your board so cables can not be so near? You could make it look like an EMI shield. Heck, a simple piece of plexiglass mounted a half inch from your board should do the job. Also, it is perfectly acceptable to specify that nothing be within some distance of your board. That is not an unusual thing for sensitive circuits.
    BTW, do you get the same sort of hang condition if you bring other metal near the oscillators? It may not be an EMI issue at all, but rather a capacitive effect on the oscillator circuit. They often are sensitive to the details of the parasitic values. If you have a resistor in series with the crystal, this might need to be reduced in value, or increased. What circuit does the manufacturer recommend for the oscillator?
    Can you provide more detail on the nature of the hang? Does the oscillator stop working? Does the frequency shift? Can you measure any of this? Just saying "without success" isn't much to go on.
    --
    Rick C.
    ---- Get 1,000 miles of free Supercharging
    ---- Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Fri May 5 10:51:52 2023
    From Newsgroup: comp.arch.embedded

    Il 04/05/2023 12:31, David Brown ha scritto:
    On 04/05/2023 10:34, pozz wrote:
    Il 03/05/2023 18:40, Rick C ha scritto:
    On Wednesday, May 3, 2023 at 12:16:49 PM UTC-4, pozz wrote:
    Il 26/04/2023 16:56, pozz ha scritto:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by >>>>> the
    SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will >>>>> use an external 32.768kHz crystal (that is multiplied by internal
    PLL to
    reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are
    related to
    the internal oscillator of ATtiny4313 that hasn't a good accuracy over >>>>> temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be
    in the
    range 0-80°C.
    I want to thank all the ones that spent some time to reply and give
    suggestions. As usual, they are valuable for me.

    I'm working on a board that is already in production. It was chosen a
    tiny for its low cost.
    The possibility to mount and use an external ceramic resonator is
    available. Moreover it has been really mounted on around 1k boards that >>>> are working now.

    However a few customers reported a problem in a few installations: the >>>> tiny blocks and only a power cycle is able to restart.

    After some tests, we found that the problem is radiated noise on the
    pins of the tiny oscillator. When power cables are near the board and
    some specific load are connected to these cables, the noise
    generated is
    capable to block the tiny.

    We tried to replace the ceramic resonator with a quartz crystal without >>>> success. We tried to strenghten the GND connection between the
    resonator/quartz and the single GND pin of the SOIC20, without success. >>>>
    The only change that seems effective in avoiding blocks is using the
    internal oscillator.

    This is the story.

    So I assume there is a reason why you can't route the power wires
    away from the ATtiny board?

    It depends. In some cases it is possible, in other cases it isn't. The
    installer isn't usually competent, so it routes cables as he wants. In
    some cases, too near my board. After some weeks or months, he
    complains the board has blocked. And he is my customer...


    I think you have been provided with all the possibilities for how to
    use the internal oscillator.  It rather comes down to "pick one".
    Are any more appealing than the others?  If you tell us what you
    don't like about it, maybe we can help refine the solution?

    At the moment we are deciding what could be the best solution.


    Do you do EMC testing for radiation emission and susceptibility?  I
    don't know what the rules and regulations are like where you are, but
    any finished product (as distinct from prototype or test systems) made
    here in Europe should be EMC certified.  If radiated noise from "normal" power cables killed a card, that would be a failure in the certification.

    Yes, of course. This problem happens only on the field in a few
    installations where cables are routed near my product, that is small and
    in a plastic enclosure.


    Or is it the surrounding system that is bad?  Maybe there is something truly terrible connected to these power cables?


    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Fri May 5 11:02:25 2023
    From Newsgroup: comp.arch.embedded

    Il 04/05/2023 15:21, Rick C ha scritto:
    On Thursday, May 4, 2023 at 4:34:25 AM UTC-4, pozz wrote:
    Il 03/05/2023 18:40, Rick C ha scritto:
    On Wednesday, May 3, 2023 at 12:16:49 PM UTC-4, pozz wrote:
    Il 26/04/2023 16:56, pozz ha scritto:
    I'd like to use async UART to let these MCUs communicate.
    The protocol will be request-response with the request generated by the >>>>> SAM MCU. The baudrate will be 38400bps.

    I'd like to use internal oscillator of ATtiny4313, while the SAM will >>>>> use an external 32.768kHz crystal (that is multiplied by internal PLL to >>>>> reach 48MHz).

    I'm not sure if this scenario can work well. My concerns are related to >>>>> the internal oscillator of ATtiny4313 that hasn't a good accuracy over >>>>> temperature and life.

    The tiny MCU will be supplied by 3.3V and its temperature will be in the >>>>> range 0-80°C.
    I want to thank all the ones that spent some time to reply and give
    suggestions. As usual, they are valuable for me.

    I'm working on a board that is already in production. It was chosen a
    tiny for its low cost.
    The possibility to mount and use an external ceramic resonator is
    available. Moreover it has been really mounted on around 1k boards that >>>> are working now.

    However a few customers reported a problem in a few installations: the >>>> tiny blocks and only a power cycle is able to restart.

    After some tests, we found that the problem is radiated noise on the
    pins of the tiny oscillator. When power cables are near the board and
    some specific load are connected to these cables, the noise generated is >>>> capable to block the tiny.

    We tried to replace the ceramic resonator with a quartz crystal without >>>> success. We tried to strenghten the GND connection between the
    resonator/quartz and the single GND pin of the SOIC20, without success. >>>>
    The only change that seems effective in avoiding blocks is using the
    internal oscillator.

    This is the story.

    So I assume there is a reason why you can't route the power wires away from the ATtiny board?
    It depends. In some cases it is possible, in other cases it isn't. The
    installer isn't usually competent, so it routes cables as he wants. In
    some cases, too near my board. After some weeks or months, he complains
    the board has blocked. And he is my customer...
    I think you have been provided with all the possibilities for how to use the internal oscillator. It rather comes down to "pick one". Are any more appealing than the others? If you tell us what you don't like about it, maybe we can help refine the solution?
    At the moment we are deciding what could be the best solution.

    Perhaps you can add an enclosure to your board so cables can not be so near? You could make it look like an EMI shield. Heck, a simple piece of plexiglass mounted a half inch from your board should do the job. Also, it is perfectly acceptable to specify that nothing be within some distance of your board. That is not an unusual thing for sensitive circuits.

    Yes, we are thinking about this solutions too.


    BTW, do you get the same sort of hang condition if you bring other metal near the oscillators? It may not be an EMI issue at all, but rather a capacitive effect on the oscillator circuit. They often are sensitive to the details of the parasitic values. If you have a resistor in series with the crystal, this might need to be reduced in value, or increased.

    No problem with capacitive loads.


    What circuit does the manufacturer recommend for the oscillator?

    Ceramic resonator has three pins, two that goes to the oscillator pins
    of the MCU and one is GND.


    Can you provide more detail on the nature of the hang? Does the oscillator stop working? Does the frequency shift? Can you measure any of this? Just saying "without success" isn't much to go on.

    The program seems stopped. Sincerely I didn't measure the oscilator
    frequency after the noise, so I don't know if it stopped completely
    and/or it is disturbed only during the noise.

    Anyway, the total effect seems a stopped program. I noticed that in some cases, this noise generates strange behaviours: GPIO connected to LED
    toggle without a reason and so on.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Fri May 5 12:59:47 2023
    From Newsgroup: comp.arch.embedded

    On 05/05/2023 10:51, pozz wrote:
    Il 04/05/2023 12:31, David Brown ha scritto:


    Do you do EMC testing for radiation emission and susceptibility?  I
    don't know what the rules and regulations are like where you are, but
    any finished product (as distinct from prototype or test systems) made
    here in Europe should be EMC certified.  If radiated noise from
    "normal" power cables killed a card, that would be a failure in the
    certification.

    Yes, of course. This problem happens only on the field in a few installations where cables are routed near my product, that is small and
    in a plastic enclosure.


    Or is it the surrounding system that is bad?  Maybe there is something
    truly terrible connected to these power cables?


    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.

    The current used for door bells - even modern monstrosities with cameras
    - is tiny. I really think something must be wrong with the card if it
    is susceptible to interference from such cables. Oscillators - crystal
    or ceramic - usually need load capacitors and a damping resistor. These
    are small loads (perhaps 15-20 pF and 10 MΩ), and are sometimes built
    into the microcontroller. But if these are missing, your oscillator
    could be unstable and easily affected by outside influence.



    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Fri May 5 18:01:41 2023
    From Newsgroup: comp.arch.embedded

    Il 05/05/2023 12:59, David Brown ha scritto:
    [...]
    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.

    The current used for door bells - even modern monstrosities with cameras
    - is tiny.

    In my installations they don't use that kind of door bells that are
    digital circuits with digital audio output. I don't know what's their
    exact name, similar to high power buzzers.


    I really think something must be wrong with the card if it
    is susceptible to interference from such cables.  Oscillators - crystal
    or ceramic - usually need load capacitors and a damping resistor.  These are small loads (perhaps 15-20 pF and 10 MΩ), and are sometimes built
    into the microcontroller.  But if these are missing, your oscillator
    could be unstable and easily affected by outside influence.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Dimiter_Popoff@dp@tgi-sci.com to comp.arch.embedded on Fri May 5 19:52:00 2023
    From Newsgroup: comp.arch.embedded

    On 5/5/2023 19:01, pozz wrote:
    Il 05/05/2023 12:59, David Brown ha scritto:
    [...]
    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.

    The current used for door bells - even modern monstrosities with
    cameras - is tiny.

    In my installations they don't use that kind of door bells that are
    digital circuits with digital audio output. I don't know what's their
    exact name, similar to high power buzzers.

    If it is some solenoid driven thing with a mechanical switch it may
    cause all sorts of interference, depending also on luck - coincidence
    between button being released, solenoid switch, sine wave peak etc.
    Try to determine whether the interference which gets you is inductive
    or capacitive, or if your board is powered off the same lines.
    Things like that can be tricky to fix, you need to understand the nature
    of what gets you first.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Fri May 5 11:37:26 2023
    From Newsgroup: comp.arch.embedded

    On Friday, May 5, 2023 at 12:03:04 PM UTC-4, pozz wrote:
    Il 05/05/2023 12:59, David Brown ha scritto:
    [...]
    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.

    The current used for door bells - even modern monstrosities with cameras
    - is tiny.
    In my installations they don't use that kind of door bells that are
    digital circuits with digital audio output. I don't know what's their
    exact name, similar to high power buzzers.
    I really think something must be wrong with the card if it
    is susceptible to interference from such cables. Oscillators - crystal
    or ceramic - usually need load capacitors and a damping resistor. These are small loads (perhaps 15-20 pF and 10 MΩ), and are sometimes built into the microcontroller. But if these are missing, your oscillator
    could be unstable and easily affected by outside influence.
    You are talking about exactly like a buzzer, but with a clapper for the bell. A mechanical switch interrupts the current to the coil and very likely arcs on opening and closing, generating significant EMI. Perhaps you could convince them to add a capacitor like they used in automotive spark systems? The spark should be in the right place.
    --
    Rick C.
    ---+ Get 1,000 miles of free Supercharging
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Grant Edwards@invalid@invalid.invalid to comp.arch.embedded on Fri May 5 20:16:03 2023
    From Newsgroup: comp.arch.embedded

    On 2023-05-05, pozz <pozzugno@gmail.com> wrote:

    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.

    People use 230VAC for _doorbells_?!?! Are they trying to wake the dead?

    Here in the US doorbells are usually 16VAC, though 24VAC is also used.
    I've also seen 10VAC and 12VAC mentioned, but I think that's uncommon.

    --
    Grant

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Sun May 7 23:17:47 2023
    From Newsgroup: comp.arch.embedded

    Il 05/05/2023 22:16, Grant Edwards ha scritto:
    On 2023-05-05, pozz <pozzugno@gmail.com> wrote:

    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.

    People use 230VAC for _doorbells_?!?! Are they trying to wake the dead?

    Here in the US doorbells are usually 16VAC, though 24VAC is also used.
    I've also seen 10VAC and 12VAC mentioned, but I think that's uncommon.

    They are very common here (for example [1]). 230Vac is the common mains voltage so the doorbells are connected to mains, through a momentary
    switch out of the door.

    [1] https://comenzielectrice.ro/pdf/Bticino%20-%20Matix%20Catalog.pdf
    Search for AM5048


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Sun May 7 23:20:59 2023
    From Newsgroup: comp.arch.embedded

    Il 05/05/2023 18:52, Dimiter_Popoff ha scritto:
    On 5/5/2023 19:01, pozz wrote:
    Il 05/05/2023 12:59, David Brown ha scritto:
    [...]
    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.

    The current used for door bells - even modern monstrosities with
    cameras - is tiny.

    In my installations they don't use that kind of door bells that are
    digital circuits with digital audio output. I don't know what's their
    exact name, similar to high power buzzers.

    If it is some solenoid driven thing with a mechanical switch it may
    cause all sorts of interference, depending also on luck - coincidence
    between button being released, solenoid switch, sine wave peak etc.
    Try to determine whether the interference which gets you is inductive
    or capacitive, or if your board is powered off the same lines.
    Things like that can be tricky to fix,

    I saw it... very well.


    you need to understand the nature of what gets you first.

    I will try. It's much more simple to avoid the problem at all disabling internal oscillator.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Sun May 7 23:21:53 2023
    From Newsgroup: comp.arch.embedded

    Il 05/05/2023 20:37, Rick C ha scritto:
    On Friday, May 5, 2023 at 12:03:04 PM UTC-4, pozz wrote:
    Il 05/05/2023 12:59, David Brown ha scritto:
    [...]
    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.

    The current used for door bells - even modern monstrosities with cameras >>> - is tiny.
    In my installations they don't use that kind of door bells that are
    digital circuits with digital audio output. I don't know what's their
    exact name, similar to high power buzzers.
    I really think something must be wrong with the card if it
    is susceptible to interference from such cables. Oscillators - crystal
    or ceramic - usually need load capacitors and a damping resistor. These >>> are small loads (perhaps 15-20 pF and 10 MΩ), and are sometimes built
    into the microcontroller. But if these are missing, your oscillator
    could be unstable and easily affected by outside influence.

    You are talking about exactly like a buzzer, but with a clapper for the bell. A mechanical switch interrupts the current to the coil and very likely arcs on opening and closing, generating significant EMI. Perhaps you could convince them to add a capacitor like they used in automotive spark systems? The spark should be in the right place.


    Ok, thanks for suggestion.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Sun May 7 14:27:43 2023
    From Newsgroup: comp.arch.embedded

    On Sunday, May 7, 2023 at 5:17:55 PM UTC-4, pozz wrote:
    Il 05/05/2023 22:16, Grant Edwards ha scritto:
    On 2023-05-05, pozz <pozz...@gmail.com> wrote:

    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.

    People use 230VAC for _doorbells_?!?! Are they trying to wake the dead?

    Here in the US doorbells are usually 16VAC, though 24VAC is also used. I've also seen 10VAC and 12VAC mentioned, but I think that's uncommon.
    They are very common here (for example [1]). 230Vac is the common mains voltage so the doorbells are connected to mains, through a momentary
    switch out of the door.

    [1] https://comenzielectrice.ro/pdf/Bticino%20-%20Matix%20Catalog.pdf
    Search for AM5048
    I don't know about where you live, but doorbells in the US are powered from low voltage, so they don't require all the safety precautions. A device on a high voltage circuit has to be mounted on a box or has to be a box rated for such wiring. A door bell uses much simpler wiring and needs no special boxes or precautions. I have seen no small number of doorbell buttons mounted directly in the door frame, having been drilled out to 1/2 inch for mounting the button.
    --
    Rick C.
    --+- Get 1,000 miles of free Supercharging
    --+- Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Mon May 8 08:34:56 2023
    From Newsgroup: comp.arch.embedded

    On 07/05/2023 23:27, Rick C wrote:
    On Sunday, May 7, 2023 at 5:17:55 PM UTC-4, pozz wrote:
    Il 05/05/2023 22:16, Grant Edwards ha scritto:
    On 2023-05-05, pozz <pozz...@gmail.com> wrote:

    The critical installations often have cables that gives mains
    power (230Vac) to coils, for example relays or door ring bell.

    People use 230VAC for _doorbells_?!?! Are they trying to wake the
    dead?

    Here in the US doorbells are usually 16VAC, though 24VAC is also
    used. I've also seen 10VAC and 12VAC mentioned, but I think
    that's uncommon.
    They are very common here (for example [1]). 230Vac is the common
    mains voltage so the doorbells are connected to mains, through a
    momentary switch out of the door.

    [1]
    https://comenzielectrice.ro/pdf/Bticino%20-%20Matix%20Catalog.pdf
    Search for AM5048

    I don't know about where you live, but doorbells in the US are
    powered from low voltage, so they don't require all the safety
    precautions. A device on a high voltage circuit has to be mounted on
    a box or has to be a box rated for such wiring. A door bell uses
    much simpler wiring and needs no special boxes or precautions. I
    have seen no small number of doorbell buttons mounted directly in the
    door frame, having been drilled out to 1/2 inch for mounting the
    button.


    Guessing from the URL, he could be in Romania, or a country near enough
    to use Romanian webshops.

    I have no idea about the regulations here in Norway, but I know our
    doorbell has a transformer in the fuse cupboard, so it does not have
    high voltage mains out to the bell. Driving mains to the doorbell
    sounds like a safety nightmare. (Mind you, it's one way to deal with
    annoying kids that ring the bell and run away...)
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Mon May 8 08:37:18 2023
    From Newsgroup: comp.arch.embedded

    On 07/05/2023 23:21, pozz wrote:
    Il 05/05/2023 20:37, Rick C ha scritto:
    On Friday, May 5, 2023 at 12:03:04 PM UTC-4, pozz wrote:
    Il 05/05/2023 12:59, David Brown ha scritto:
    [...]
    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.

    The current used for door bells - even modern monstrosities with
    cameras
    - is tiny.
    In my installations they don't use that kind of door bells that are
    digital circuits with digital audio output. I don't know what's their
    exact name, similar to high power buzzers.
    I really think something must be wrong with the card if it
    is susceptible to interference from such cables.  Oscillators - crystal >>>> or ceramic - usually need load capacitors and a damping resistor.
    These
    are small loads (perhaps 15-20 pF and 10 MΩ), and are sometimes built >>>> into the microcontroller.  But if these are missing, your oscillator
    could be unstable and easily affected by outside influence.

    You are talking about exactly like a buzzer, but with a clapper for
    the bell.  A mechanical switch interrupts the current to the coil and
    very likely arcs on opening and closing, generating significant EMI.
    Perhaps you could convince them to add a capacitor like they used in
    automotive spark systems?  The spark should be in the right place.


    Ok, thanks for suggestion.

    Another thing to check is exactly where the noise gets into your system.
    Maybe it is actually coming in through wires (such as power supply
    wires) connected to your box, rather than directly from the bell wire to
    the PCB traces. Do you have any connecting wires that might be run
    parallel to the bell wire, acting as antenna? If so, try a capacitor on
    those lines as a simple EMC filter.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Mon May 8 09:24:17 2023
    From Newsgroup: comp.arch.embedded

    Il 08/05/2023 08:37, David Brown ha scritto:
    On 07/05/2023 23:21, pozz wrote:
    Il 05/05/2023 20:37, Rick C ha scritto:
    On Friday, May 5, 2023 at 12:03:04 PM UTC-4, pozz wrote:
    Il 05/05/2023 12:59, David Brown ha scritto:
    [...]
    The critical installations often have cables that gives mains power >>>>>> (230Vac) to coils, for example relays or door ring bell.

    The current used for door bells - even modern monstrosities with
    cameras
    - is tiny.
    In my installations they don't use that kind of door bells that are
    digital circuits with digital audio output. I don't know what's their
    exact name, similar to high power buzzers.
    I really think something must be wrong with the card if it
    is susceptible to interference from such cables.  Oscillators -
    crystal
    or ceramic - usually need load capacitors and a damping resistor.
    These
    are small loads (perhaps 15-20 pF and 10 MΩ), and are sometimes built >>>>> into the microcontroller.  But if these are missing, your oscillator >>>>> could be unstable and easily affected by outside influence.

    You are talking about exactly like a buzzer, but with a clapper for
    the bell.  A mechanical switch interrupts the current to the coil and
    very likely arcs on opening and closing, generating significant EMI.
    Perhaps you could convince them to add a capacitor like they used in
    automotive spark systems?  The spark should be in the right place.


    Ok, thanks for suggestion.

    Another thing to check is exactly where the noise gets into your system.
     Maybe it is actually coming in through wires (such as power supply
    wires) connected to your box, rather than directly from the bell wire to
    the PCB traces.  Do you have any connecting wires that might be run parallel to the bell wire, acting as antenna?  If so, try a capacitor on those lines as a simple EMC filter.

    My board is not so sensitive. You need to put the cables near my plastic enclosure, exactly over the resonator. If you route the cables far from
    the resonator/oscillator pins, the problem disappears, even if I tie all
    the cables together (ring cables and 12Vdc power supply cables of my board). --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Mon May 8 09:38:10 2023
    From Newsgroup: comp.arch.embedded

    Il 07/05/2023 23:27, Rick C ha scritto:
    On Sunday, May 7, 2023 at 5:17:55 PM UTC-4, pozz wrote:
    Il 05/05/2023 22:16, Grant Edwards ha scritto:
    On 2023-05-05, pozz <pozz...@gmail.com> wrote:

    The critical installations often have cables that gives mains power
    (230Vac) to coils, for example relays or door ring bell.

    People use 230VAC for _doorbells_?!?! Are they trying to wake the dead?

    Here in the US doorbells are usually 16VAC, though 24VAC is also used.
    I've also seen 10VAC and 12VAC mentioned, but I think that's uncommon.
    They are very common here (for example [1]). 230Vac is the common mains
    voltage so the doorbells are connected to mains, through a momentary
    switch out of the door.

    [1] https://comenzielectrice.ro/pdf/Bticino%20-%20Matix%20Catalog.pdf
    Search for AM5048

    I don't know about where you live, but doorbells in the US are powered from low voltage, so they don't require all the safety precautions.

    So you have a dedicated power supply for doorbells? Here 99% of house doorbells are 230Vac. The installation is much more easy, because you
    use directly the mains cables without additional hw.

    The pushbutton that activates the doorbells are a normal button (but momentary) that could be used to activate lights in the room.


    A device on a high voltage circuit has to be mounted on a box or has to be a box rated for such wiring. A door bell uses much simpler wiring and needs no special boxes or precautions. I have seen no small number of doorbell buttons mounted directly in the door frame, having been drilled out to 1/2 inch for mounting the button.


    In the past, the doorbells were dedicated box mounted on the wall, near
    the door, inside the apartment.

    Now they tend to install as a module inside push-button frames that are "inside" the wall ([1] just as an example).

    Anyway my board is not near the buzzer, but could be near the pushbutton
    that activates the buzzer.

    [1] https://www.rmelectric.it/3054-large_default/ronzatore-vimar-plana-230v-bianco-suoneria-campanello-segnalatore-acustico-14378.jpg
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Dimiter_Popoff@dp@tgi-sci.com to comp.arch.embedded on Mon May 8 13:46:37 2023
    From Newsgroup: comp.arch.embedded

    On 5/8/2023 9:34, David Brown wrote:
    On 07/05/2023 23:27, Rick C wrote:
    On Sunday, May 7, 2023 at 5:17:55 PM UTC-4, pozz wrote:
    Il 05/05/2023 22:16, Grant Edwards ha scritto:
    On 2023-05-05, pozz <pozz...@gmail.com> wrote:

    The critical installations often have cables that gives mains
    power (230Vac) to coils, for example relays or door ring bell.

    People use 230VAC for _doorbells_?!?! Are they trying to wake the
    dead?

    Here in the US doorbells are usually 16VAC, though 24VAC is also
    used. I've also seen 10VAC and 12VAC mentioned, but I think
    that's uncommon.
    They are very common here (for example [1]). 230Vac is the common
    mains voltage so the doorbells are connected to mains, through a
    momentary switch out of the door.

    [1]
    https://comenzielectrice.ro/pdf/Bticino%20-%20Matix%20Catalog.pdf
    Search for AM5048

    I don't know about where you live, but doorbells in the US are
    powered from low voltage, so they don't require all the safety
    precautions.  A device on a high voltage circuit has to be mounted on
    a box or has to be a box rated for such wiring.  A door bell uses
    much simpler wiring and needs no special boxes or precautions.  I
    have seen no small number of doorbell buttons mounted directly in the
    door frame, having been drilled out to 1/2 inch for mounting the
    button.


    Guessing from the URL, he could be in Romania, or a country near enough
    to use Romanian webshops.

    I have no idea about the regulations here in Norway, but I know our
    doorbell has a transformer in the fuse cupboard, so it does not have
    high voltage mains out to the bell.  Driving mains to the doorbell
    sounds like a safety nightmare.  (Mind you, it's one way to deal with annoying kids that ring the bell and run away...)

    Similar here (Bulgaria). When I was a kid starting to try to put
    together this or that a "doorbell transformer" was a popular
    option to make some sort of power supply. I think they had a few
    outputs at the secondary, starting at 6V or something.
    But even so if the buzzer has nasty solenoids and switches it
    can cause plenty of interference, who knows.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Grant Edwards@invalid@invalid.invalid to comp.arch.embedded on Mon May 8 14:12:06 2023
    From Newsgroup: comp.arch.embedded

    On 2023-05-08, pozz <pozzugno@gmail.com> wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:

    I don't know about where you live, but doorbells in the US are
    powered from low voltage, so they don't require all the safety
    precautions.

    So you have a dedicated power supply for doorbells?

    Yes. A small transformer that costs a couple dollars. It allows use of
    far cheaper wiring and switches than would be required for 120V and
    avoids requirements for approved junction boxes, etc.


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Mon May 8 07:32:37 2023
    From Newsgroup: comp.arch.embedded

    On Monday, May 8, 2023 at 3:38:15 AM UTC-4, pozz wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:
    On Sunday, May 7, 2023 at 5:17:55 PM UTC-4, pozz wrote:
    Il 05/05/2023 22:16, Grant Edwards ha scritto:
    On 2023-05-05, pozz <pozz...@gmail.com> wrote:

    The critical installations often have cables that gives mains power >>>> (230Vac) to coils, for example relays or door ring bell.

    People use 230VAC for _doorbells_?!?! Are they trying to wake the dead? >>>
    Here in the US doorbells are usually 16VAC, though 24VAC is also used. >>> I've also seen 10VAC and 12VAC mentioned, but I think that's uncommon. >> They are very common here (for example [1]). 230Vac is the common mains >> voltage so the doorbells are connected to mains, through a momentary
    switch out of the door.

    [1] https://comenzielectrice.ro/pdf/Bticino%20-%20Matix%20Catalog.pdf
    Search for AM5048

    I don't know about where you live, but doorbells in the US are powered from low voltage, so they don't require all the safety precautions.
    So you have a dedicated power supply for doorbells?
    LOL, when you say "dedicated power supply", you mean this. https://www.amazon.com/HQRP-Transformer-Compatible-8v-16v-24v-Replacement/dp/B094DKV9NQ
    The high voltage side of the transformer is mounted on a proper high voltage box. The rest of the wiring is low voltage, so requires no particular safety precautions. The power is low, so even at the low voltage the wire is not heavy, typically 20 or 22 gauge.
    Here 99% of house
    doorbells are 230Vac. The installation is much more easy, because you
    use directly the mains cables without additional hw.
    Doesn't the button require a much more substantial mounting, as well as the bell itself? That's what the low voltage is avoiding. I think my transformer is mounted in the pantry ceiling not unlike a lightbulb (which is also in the pantry ceiling).
    The pushbutton that activates the doorbells are a normal button (but momentary) that could be used to activate lights in the room.
    I don't know what that means "normal". Here, all wiring junctions or terminations must be done in an approved box.
    https://www.youtube.com/watch?v=6GUODvOVz10
    The wire junctions shown here are valid, but not common in the US. Mostly people are used to "wire nuts", which are like this, and work well.
    https://www.cableorganizer.com/categories/electrical-supplies/cable-termination/tan-wire-connector/
    The mistake that is often made when using them, is to not twist the wires together before twisting the nut on. The nut is not intended to be a mechanical connection, just electrical. So the insulated portion of the wire should be twisted together first.
    A device on a high voltage circuit has to be mounted on a box or has to be a box rated for such wiring. A door bell uses much simpler wiring and needs no special boxes or precautions. I have seen no small number of doorbell buttons mounted directly in the door frame, having been drilled out to 1/2 inch for mounting the button.

    In the past, the doorbells were dedicated box mounted on the wall, near
    the door, inside the apartment.

    Now they tend to install as a module inside push-button frames that are "inside" the wall ([1] just as an example).

    Anyway my board is not near the buzzer, but could be near the pushbutton that activates the buzzer.

    [1] https://www.rmelectric.it/3054-large_default/ronzatore-vimar-plana-230v-bianco-suoneria-campanello-segnalatore-acustico-14378.jpg
    The bell itself is not an issue. The PITA is the button. https://www.amazon.com/doorbell-push-button/s?k=doorbell+push+button
    These are much easier to mount where they are most convenient. See the small button with the screw terminals? Below is a crude video of a similar button showing the minimal requirements for installation. This guy is upgrading to a video doorbell.
    https://www.google.com/search?q=round+doorbell+button+mounting&client=firefox-b-1-d&sxsrf=APwXEdfIYgYKthf4KothWTYEIfsvEMSPHg:1683555901893&source=lnms&tbm=vid&sa=X&ved=2ahUKEwj2l_e79uX-AhXaMVkFHVUuBuUQ0pQJegQIMBAG&biw=923&bih=497&dpr=1.94#fpstate=ive&vld=cid:1132e9ee,vid:N0H1jSUySH0
    Much simpler and less expensive than running high voltage wiring to the button.
    I'm wondering if your doorbell has the low voltage transformer inside and the wire to your doorbell is also low voltage? It just makes zero sense to run high voltage to the button.
    --
    Rick C.
    --++ Get 1,000 miles of free Supercharging
    --++ Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Mon May 8 18:13:30 2023
    From Newsgroup: comp.arch.embedded

    Il 08/05/2023 16:12, Grant Edwards ha scritto:
    On 2023-05-08, pozz <pozzugno@gmail.com> wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:

    I don't know about where you live, but doorbells in the US are
    powered from low voltage, so they don't require all the safety
    precautions.

    So you have a dedicated power supply for doorbells?

    Yes. A small transformer that costs a couple dollars. It allows use of
    far cheaper wiring and switches than would be required for 120V and
    avoids requirements for approved junction boxes, etc.

    I understand a small transformer is cheap, but anyway it's cheaper and
    simpler not having it at all.

    Here cables for doorbells are routed together with other cables, for
    example for lightning, so they uses the same junction boxes.
    Moreover the push-button for the doorbell is identical to the one used
    to switch on a lamp. It's not uncommon to have a 230Vac frame with
    push-button for doorbell, push-button to activate outdoor lamps and a
    RFID reader to disable the anti-burglar system. All these three elements
    in a frame like this.

    [1] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Mon May 8 18:27:11 2023
    From Newsgroup: comp.arch.embedded

    Il 08/05/2023 16:32, Rick C ha scritto:
    On Monday, May 8, 2023 at 3:38:15 AM UTC-4, pozz wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:
    On Sunday, May 7, 2023 at 5:17:55 PM UTC-4, pozz wrote:
    Il 05/05/2023 22:16, Grant Edwards ha scritto:
    On 2023-05-05, pozz <pozz...@gmail.com> wrote:

    The critical installations often have cables that gives mains power >>>>>> (230Vac) to coils, for example relays or door ring bell.

    People use 230VAC for _doorbells_?!?! Are they trying to wake the dead? >>>>>
    Here in the US doorbells are usually 16VAC, though 24VAC is also used. >>>>> I've also seen 10VAC and 12VAC mentioned, but I think that's uncommon. >>>> They are very common here (for example [1]). 230Vac is the common mains >>>> voltage so the doorbells are connected to mains, through a momentary
    switch out of the door.

    [1] https://comenzielectrice.ro/pdf/Bticino%20-%20Matix%20Catalog.pdf
    Search for AM5048

    I don't know about where you live, but doorbells in the US are powered from low voltage, so they don't require all the safety precautions.
    So you have a dedicated power supply for doorbells?

    LOL, when you say "dedicated power supply", you mean this.

    https://www.amazon.com/HQRP-Transformer-Compatible-8v-16v-24v-Replacement/dp/B094DKV9NQ

    The price on this link is 23 euros, I think a 230Vac doorbell costs less.


    The high voltage side of the transformer is mounted on a proper high voltage box. The rest of the wiring is low voltage, so requires no particular safety precautions. The power is low, so even at the low voltage the wire is not heavy, typically 20 or 22 gauge.

    Here they usually route the doorbell 230Vac cables together with other
    cable of electrical system (lightning...) using the same junction boxes.


    Here 99% of house
    doorbells are 230Vac. The installation is much more easy, because you
    use directly the mains cables without additional hw.

    Doesn't the button require a much more substantial mounting, as well as the bell itself? That's what the low voltage is avoiding. I think my transformer is mounted in the pantry ceiling not unlike a lightbulb (which is also in the pantry ceiling).

    See [1]. That is a 3-modules frame that can be installed in the wall.
    It's already compatible with 230Vac push-buttons. With one of this you
    can have the push-button for an outdoor lamp, a push-button for the
    doorbell and a keytag reader for anti-burglar system (for example).

    You don't need an additional substantial mounting dedicated for doorbell pushbutton.


    The pushbutton that activates the doorbells are a normal button (but
    momentary) that could be used to activate lights in the room.

    I don't know what that means "normal". Here, all wiring junctions or terminations must be done in an approved box.

    Yes, of course. The same box used for a switch that turns on a light.
    There's no need to add a dedicated box for doorbell.


    https://www.youtube.com/watch?v=6GUODvOVz10

    The wire junctions shown here are valid, but not common in the US. Mostly people are used to "wire nuts", which are like this, and work well.

    https://www.cableorganizer.com/categories/electrical-supplies/cable-termination/tan-wire-connector/

    The mistake that is often made when using them, is to not twist the wires together before twisting the nut on. The nut is not intended to be a mechanical connection, just electrical. So the insulated portion of the wire should be twisted together first.


    A device on a high voltage circuit has to be mounted on a box or has to be a box rated for such wiring. A door bell uses much simpler wiring and needs no special boxes or precautions. I have seen no small number of doorbell buttons mounted directly in the door frame, having been drilled out to 1/2 inch for mounting the button.

    In the past, the doorbells were dedicated box mounted on the wall, near
    the door, inside the apartment.

    Now they tend to install as a module inside push-button frames that are
    "inside" the wall ([1] just as an example).

    Anyway my board is not near the buzzer, but could be near the pushbutton
    that activates the buzzer.

    [1]
    https://www.rmelectric.it/3054-large_default/ronzatore-vimar-plana-230v-bianco-suoneria-campanello-segnalatore-acustico-14378.jpg

    The bell itself is not an issue. The PITA is the button.

    https://www.amazon.com/doorbell-push-button/s?k=doorbell+push+button

    These are much easier to mount where they are most convenient. See the small button with the screw terminals? Below is a crude video of a similar button showing the minimal requirements for installation. This guy is upgrading to a video doorbell.

    https://www.google.com/search?q=round+doorbell+button+mounting&client=firefox-b-1-d&sxsrf=APwXEdfIYgYKthf4KothWTYEIfsvEMSPHg:1683555901893&source=lnms&tbm=vid&sa=X&ved=2ahUKEwj2l_e79uX-AhXaMVkFHVUuBuUQ0pQJegQIMBAG&biw=923&bih=497&dpr=1.94#fpstate=ive&vld=cid:1132e9ee,vid:N0H1jSUySH0

    Much simpler and less expensive than running high voltage wiring to the button.

    If you have only a doorbell pushbutton outdoor, yes it could be simpler. However here usually installs a "normal" in-the-wall 3-modules box, so
    you can have multiples commodities: doorbell push-button, button for a
    light and so on. This box is already compatible for 230Vac signals.


    I'm wondering if your doorbell has the low voltage transformer inside and the wire to your doorbell is also low voltage? It just makes zero sense to run high voltage to the button.


    [1] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Mon May 8 11:39:09 2023
    From Newsgroup: comp.arch.embedded

    On Monday, May 8, 2023 at 12:15:19 PM UTC-4, pozz wrote:
    Il 08/05/2023 16:12, Grant Edwards ha scritto:
    On 2023-05-08, pozz <pozz...@gmail.com> wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:

    I don't know about where you live, but doorbells in the US are
    powered from low voltage, so they don't require all the safety
    precautions.

    So you have a dedicated power supply for doorbells?

    Yes. A small transformer that costs a couple dollars. It allows use of
    far cheaper wiring and switches than would be required for 120V and
    avoids requirements for approved junction boxes, etc.
    I understand a small transformer is cheap, but anyway it's cheaper and simpler not having it at all.
    LOL You don't seem to understand. You either have the transformer as a separate entity, or its functionality is incorporated in something more expensive, because it is rated for 240V.
    Here cables for doorbells are routed together with other cables, for
    example for lightning, so they uses the same junction boxes.
    I think you mean "lighting". But you can't lump the doorbell with anything else. At least not in existing construction. It is all irrelevant. Do what you wish. Spend the money on 240V wiring at a dollar a foot and high voltage boxes. That's your choice. But the fact is, the low voltage doorbell is much cheaper to install.
    Moreover the push-button for the doorbell is identical to the one used
    to switch on a lamp. It's not uncommon to have a 230Vac frame with push-button for doorbell, push-button to activate outdoor lamps and a
    RFID reader to disable the anti-burglar system. All these three elements
    in a frame like this.
    You put your outside lights on an outside switch? Doesn't happen here, at least not at the front door.
    [1] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png
    Your photo looks like an indoor switch. Outdoor switches are typically much more robust and sealed from the elements. Which one is the doorbell switch? Or is all this inside the front door and a visitor opens the door to ring the bell?
    --
    Rick C.
    -+-- Get 1,000 miles of free Supercharging
    -+-- Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Mon May 8 11:52:12 2023
    From Newsgroup: comp.arch.embedded

    On Monday, May 8, 2023 at 12:29:21 PM UTC-4, pozz wrote:
    Il 08/05/2023 16:32, Rick C ha scritto:
    On Monday, May 8, 2023 at 3:38:15 AM UTC-4, pozz wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:
    On Sunday, May 7, 2023 at 5:17:55 PM UTC-4, pozz wrote:
    Il 05/05/2023 22:16, Grant Edwards ha scritto:
    On 2023-05-05, pozz <pozz...@gmail.com> wrote:

    The critical installations often have cables that gives mains power >>>>>> (230Vac) to coils, for example relays or door ring bell.

    People use 230VAC for _doorbells_?!?! Are they trying to wake the dead?

    Here in the US doorbells are usually 16VAC, though 24VAC is also used. >>>>> I've also seen 10VAC and 12VAC mentioned, but I think that's uncommon. >>>> They are very common here (for example [1]). 230Vac is the common mains >>>> voltage so the doorbells are connected to mains, through a momentary >>>> switch out of the door.

    [1] https://comenzielectrice.ro/pdf/Bticino%20-%20Matix%20Catalog.pdf >>>> Search for AM5048

    I don't know about where you live, but doorbells in the US are powered from low voltage, so they don't require all the safety precautions.
    So you have a dedicated power supply for doorbells?

    LOL, when you say "dedicated power supply", you mean this.

    https://www.amazon.com/HQRP-Transformer-Compatible-8v-16v-24v-Replacement/dp/B094DKV9NQ
    The price on this link is 23 euros, I think a 230Vac doorbell costs less.
    Yeah, Amazon is often the highest price for various items. The transformer is as little as $8 in local stores.
    The high voltage side of the transformer is mounted on a proper high voltage box. The rest of the wiring is low voltage, so requires no particular safety precautions. The power is low, so even at the low voltage the wire is not heavy, typically 20 or 22 gauge.
    Here they usually route the doorbell 230Vac cables together with other
    cable of electrical system (lightning...) using the same junction boxes.
    "Routing" typically needs no boxes. You still need a box for the button and for the bell. I'm sure you are not grasping the simplicity of a low voltage doorbell.
    Here 99% of house
    doorbells are 230Vac. The installation is much more easy, because you
    use directly the mains cables without additional hw.

    Doesn't the button require a much more substantial mounting, as well as the bell itself? That's what the low voltage is avoiding. I think my transformer is mounted in the pantry ceiling not unlike a lightbulb (which is also in the pantry ceiling).
    See [1]. That is a 3-modules frame that can be installed in the wall.
    It's already compatible with 230Vac push-buttons. With one of this you
    can have the push-button for an outdoor lamp, a push-button for the
    doorbell and a keytag reader for anti-burglar system (for example).
    Is it for outdoor use??? The only items I found were the 12V power supply.
    You don't need an additional substantial mounting dedicated for doorbell pushbutton.
    I have no idea what you are describing. No one I've ever known has high voltage light switches mounted next to the front door with or without a bell button. In fact, it's not allowed to mix low voltage and high voltage in the same box.
    The pushbutton that activates the doorbells are a normal button (but
    momentary) that could be used to activate lights in the room.

    I don't know what that means "normal". Here, all wiring junctions or terminations must be done in an approved box.
    Yes, of course. The same box used for a switch that turns on a light. There's no need to add a dedicated box for doorbell.
    You keep saying that, but you have to put in an unsightly and obtrusive high voltage box, next to your front door. If you want to put other high voltage switches in that, fine, but it doesn't change the need for the high voltage box for the doorbell button.
    https://www.youtube.com/watch?v=6GUODvOVz10

    The wire junctions shown here are valid, but not common in the US. Mostly people are used to "wire nuts", which are like this, and work well.

    https://www.cableorganizer.com/categories/electrical-supplies/cable-termination/tan-wire-connector/

    The mistake that is often made when using them, is to not twist the wires together before twisting the nut on. The nut is not intended to be a mechanical connection, just electrical. So the insulated portion of the wire should be twisted together first.


    A device on a high voltage circuit has to be mounted on a box or has to be a box rated for such wiring. A door bell uses much simpler wiring and needs no special boxes or precautions. I have seen no small number of doorbell buttons mounted directly in the door frame, having been drilled out to 1/2 inch for mounting the button.

    In the past, the doorbells were dedicated box mounted on the wall, near >> the door, inside the apartment.

    Now they tend to install as a module inside push-button frames that are >> "inside" the wall ([1] just as an example).

    Anyway my board is not near the buzzer, but could be near the pushbutton >> that activates the buzzer.

    [1]
    https://www.rmelectric.it/3054-large_default/ronzatore-vimar-plana-230v-bianco-suoneria-campanello-segnalatore-acustico-14378.jpg

    The bell itself is not an issue. The PITA is the button.

    https://www.amazon.com/doorbell-push-button/s?k=doorbell+push+button

    These are much easier to mount where they are most convenient. See the small button with the screw terminals? Below is a crude video of a similar button showing the minimal requirements for installation. This guy is upgrading to a video doorbell.

    https://www.google.com/search?q=round+doorbell+button+mounting&client=firefox-b-1-d&sxsrf=APwXEdfIYgYKthf4KothWTYEIfsvEMSPHg:1683555901893&source=lnms&tbm=vid&sa=X&ved=2ahUKEwj2l_e79uX-AhXaMVkFHVUuBuUQ0pQJegQIMBAG&biw=923&bih=497&dpr=1.94#fpstate=ive&vld=cid:1132e9ee,vid:N0H1jSUySH0

    Much simpler and less expensive than running high voltage wiring to the button.
    If you have only a doorbell pushbutton outdoor, yes it could be simpler. However here usually installs a "normal" in-the-wall 3-modules box, so
    you can have multiples commodities: doorbell push-button, button for a
    light and so on. This box is already compatible for 230Vac signals.
    I'm wondering if your doorbell has the low voltage transformer inside and the wire to your doorbell is also low voltage? It just makes zero sense to run high voltage to the button.

    [1] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png
    Why do you keep showing pictures of indoor switches? This has nothing to do with the outside doorbell button.
    I did find this in your catalog.
    bronze bell 12 Va.c. - 5 VA - 80 dB
    --
    Rick C.
    -+-+ Get 1,000 miles of free Supercharging
    -+-+ Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Grant Edwards@invalid@invalid.invalid to comp.arch.embedded on Mon May 8 19:09:19 2023
    From Newsgroup: comp.arch.embedded

    On 2023-05-08, pozz <pozzugno@gmail.com> wrote:
    Il 08/05/2023 16:12, Grant Edwards ha scritto:
    On 2023-05-08, pozz <pozzugno@gmail.com> wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:

    I don't know about where you live, but doorbells in the US are
    powered from low voltage, so they don't require all the safety
    precautions.

    So you have a dedicated power supply for doorbells?

    Yes. A small transformer that costs a couple dollars. It allows use of
    far cheaper wiring and switches than would be required for 120V and
    avoids requirements for approved junction boxes, etc.

    I understand a small transformer is cheap, but anyway it's cheaper and simpler not having it at all.

    It's hard to see how the installed cost could cheaper. Using 16V
    allows use of much cheaper wire, you don't need to install junction
    boxes or conduit, the routing requirements for mains voltages don't
    apply, and you don't need a certified electrician to do the work.

    Here cables for doorbells are routed together with other cables, for
    example for lightning, so they uses the same junction boxes.

    There's a junction box on the outside of the house for light switches?

    Moreover the push-button for the doorbell is identical to the one used
    to switch on a lamp. It's not uncommon to have a 230Vac frame with push-button for doorbell, push-button to activate outdoor lamps and a
    RFID reader to disable the anti-burglar system. All these three elements
    in a frame like this.

    [1] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png

    Those switches are on the outside of the house and one of them is the
    doorbell button?

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Tue May 9 16:52:23 2023
    From Newsgroup: comp.arch.embedded

    Il 08/05/2023 20:52, Rick C ha scritto:
    On Monday, May 8, 2023 at 12:29:21 PM UTC-4, pozz wrote:
    Il 08/05/2023 16:32, Rick C ha scritto:
    On Monday, May 8, 2023 at 3:38:15 AM UTC-4, pozz wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:
    On Sunday, May 7, 2023 at 5:17:55 PM UTC-4, pozz wrote:
    Il 05/05/2023 22:16, Grant Edwards ha scritto:
    On 2023-05-05, pozz <pozz...@gmail.com> wrote:

    The critical installations often have cables that gives mains power >>>>>>>> (230Vac) to coils, for example relays or door ring bell.

    People use 230VAC for _doorbells_?!?! Are they trying to wake the dead? >>>>>>>
    Here in the US doorbells are usually 16VAC, though 24VAC is also used. >>>>>>> I've also seen 10VAC and 12VAC mentioned, but I think that's uncommon. >>>>>> They are very common here (for example [1]). 230Vac is the common mains >>>>>> voltage so the doorbells are connected to mains, through a momentary >>>>>> switch out of the door.

    [1] https://comenzielectrice.ro/pdf/Bticino%20-%20Matix%20Catalog.pdf >>>>>> Search for AM5048

    I don't know about where you live, but doorbells in the US are powered from low voltage, so they don't require all the safety precautions.
    So you have a dedicated power supply for doorbells?

    LOL, when you say "dedicated power supply", you mean this.

    https://www.amazon.com/HQRP-Transformer-Compatible-8v-16v-24v-Replacement/dp/B094DKV9NQ
    The price on this link is 23 euros, I think a 230Vac doorbell costs less.

    Yeah, Amazon is often the highest price for various items. The transformer is as little as $8 in local stores.


    The high voltage side of the transformer is mounted on a proper high voltage box. The rest of the wiring is low voltage, so requires no particular safety precautions. The power is low, so even at the low voltage the wire is not heavy, typically 20 or 22 gauge.
    Here they usually route the doorbell 230Vac cables together with other
    cable of electrical system (lightning...) using the same junction boxes.

    "Routing" typically needs no boxes. You still need a box for the button and for the bell. I'm sure you are not grasping the simplicity of a low voltage doorbell.

    I don't want to defend installations that THEY do here where I live. I'm
    just describing what usually happens.

    In the apartment there are already "in-wall" tubes and junction boxes
    for mains distribution and frames for lights switches. In this case, I
    think it's worth it to "waste" one module to install a 230Vac buzzer
    inside and one module to install a 230Vac pushbutton to activate the
    buzzer outside. During installation of mains circuits you already have
    230Vac cables and you can use them for doorbell too.

    The prices of 230Vac and 12Vac doorbells are similar (see [1] and [2]),
    with the plus you can avoid an additional power supply/transformer, even
    if it is cheap.


    Here 99% of house
    doorbells are 230Vac. The installation is much more easy, because you
    use directly the mains cables without additional hw.

    Doesn't the button require a much more substantial mounting, as well as the bell itself? That's what the low voltage is avoiding. I think my transformer is mounted in the pantry ceiling not unlike a lightbulb (which is also in the pantry ceiling).
    See [1]. That is a 3-modules frame that can be installed in the wall.
    It's already compatible with 230Vac push-buttons. With one of this you
    can have the push-button for an outdoor lamp, a push-button for the
    doorbell and a keytag reader for anti-burglar system (for example).

    Is it for outdoor use??? The only items I found were the 12V power supply.

    Sorry for misunderstanding. It isn't for outdoor use, it is usually
    installed "out of the door" of the apartment, but inside a
    multi-apartment building.
    Of course, in isolated building where the doorbell switch is really
    outdoor, you can't use that.


    You don't need an additional substantial mounting dedicated for doorbell
    pushbutton.

    I have no idea what you are describing. No one I've ever known has high voltage light switches mounted next to the front door with or without a bell button. In fact, it's not allowed to mix low voltage and high voltage in the same box.

    When the apartment is one of many in a building (condominium), there's
    usually a public light on the common part of the floor (balcony?
    landing?) inside the building. And you could want to switch on when you
    are outside your apartment. Both the light button and doorbell button
    are 230Vac, so no mixing.


    The pushbutton that activates the doorbells are a normal button (but
    momentary) that could be used to activate lights in the room.

    I don't know what that means "normal". Here, all wiring junctions or terminations must be done in an approved box.
    Yes, of course. The same box used for a switch that turns on a light.
    There's no need to add a dedicated box for doorbell.

    You keep saying that, but you have to put in an unsightly and obtrusive high voltage box, next to your front door. If you want to put other high voltage switches in that, fine, but it doesn't change the need for the high voltage box for the doorbell button.

    I don't think this[3] is worse than this[4]. Of course, it depends on
    personal taste.


    https://www.youtube.com/watch?v=6GUODvOVz10

    The wire junctions shown here are valid, but not common in the US. Mostly people are used to "wire nuts", which are like this, and work well.

    https://www.cableorganizer.com/categories/electrical-supplies/cable-termination/tan-wire-connector/

    The mistake that is often made when using them, is to not twist the wires together before twisting the nut on. The nut is not intended to be a mechanical connection, just electrical. So the insulated portion of the wire should be twisted together first.


    A device on a high voltage circuit has to be mounted on a box or has to be a box rated for such wiring. A door bell uses much simpler wiring and needs no special boxes or precautions. I have seen no small number of doorbell buttons mounted directly in the door frame, having been drilled out to 1/2 inch for mounting the button.

    In the past, the doorbells were dedicated box mounted on the wall, near >>>> the door, inside the apartment.

    Now they tend to install as a module inside push-button frames that are >>>> "inside" the wall ([1] just as an example).

    Anyway my board is not near the buzzer, but could be near the pushbutton >>>> that activates the buzzer.

    [1]
    https://www.rmelectric.it/3054-large_default/ronzatore-vimar-plana-230v-bianco-suoneria-campanello-segnalatore-acustico-14378.jpg

    The bell itself is not an issue. The PITA is the button.

    https://www.amazon.com/doorbell-push-button/s?k=doorbell+push+button

    These are much easier to mount where they are most convenient. See the small button with the screw terminals? Below is a crude video of a similar button showing the minimal requirements for installation. This guy is upgrading to a video doorbell.

    https://www.google.com/search?q=round+doorbell+button+mounting&client=firefox-b-1-d&sxsrf=APwXEdfIYgYKthf4KothWTYEIfsvEMSPHg:1683555901893&source=lnms&tbm=vid&sa=X&ved=2ahUKEwj2l_e79uX-AhXaMVkFHVUuBuUQ0pQJegQIMBAG&biw=923&bih=497&dpr=1.94#fpstate=ive&vld=cid:1132e9ee,vid:N0H1jSUySH0

    Much simpler and less expensive than running high voltage wiring to the button.
    If you have only a doorbell pushbutton outdoor, yes it could be simpler.
    However here usually installs a "normal" in-the-wall 3-modules box, so
    you can have multiples commodities: doorbell push-button, button for a
    light and so on. This box is already compatible for 230Vac signals.
    I'm wondering if your doorbell has the low voltage transformer inside and the wire to your doorbell is also low voltage? It just makes zero sense to run high voltage to the button.

    [1] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png

    Why do you keep showing pictures of indoor switches? This has nothing to do with the outside doorbell button.

    See above for the misunderstanding.


    I did find this in your catalog.

    bronze bell 12 Va.c. - 5 VA - 80 dB

    Yes, I never said there aren't low voltage buzzers, but they aren't
    frequently used here.


    [1] https://amzn.eu/d/8iPOXgt
    [2] https://amzn.eu/d/b31Lcre
    [3] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png
    [4] https://m.media-amazon.com/images/I/71hYNep5oaL._AC_SL1200_.jpg
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Tue May 9 17:04:01 2023
    From Newsgroup: comp.arch.embedded

    Il 08/05/2023 20:39, Rick C ha scritto:
    On Monday, May 8, 2023 at 12:15:19 PM UTC-4, pozz wrote:
    Il 08/05/2023 16:12, Grant Edwards ha scritto:
    On 2023-05-08, pozz <pozz...@gmail.com> wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:

    I don't know about where you live, but doorbells in the US are
    powered from low voltage, so they don't require all the safety
    precautions.

    So you have a dedicated power supply for doorbells?

    Yes. A small transformer that costs a couple dollars. It allows use of
    far cheaper wiring and switches than would be required for 120V and
    avoids requirements for approved junction boxes, etc.
    I understand a small transformer is cheap, but anyway it's cheaper and
    simpler not having it at all.

    LOL You don't seem to understand. You either have the transformer as a separate entity, or its functionality is incorporated in something more expensive, because it is rated for 240V.

    See [1] and [2]. The prices are the same.


    Here cables for doorbells are routed together with other cables, for
    example for lightning, so they uses the same junction boxes.

    I think you mean "lighting".

    Yes, sorry.


    But you can't lump the doorbell with anything else. At least not in existing construction. It is all irrelevant. Do what you wish. Spend the money on 240V wiring at a dollar a foot and high voltage boxes. That's your choice. But the fact is, the low voltage doorbell is much cheaper to install.

    I don't want to spend any money for any doorbells ;-)
    This is what I see, I'm not an expert of mains distribution in buildings
    and apartments.

    I'm only supposing that in a new house, where you already have 230Vac
    tubes and junction boxes and you need one or more light push-buttons out
    of the door (not outdoor), you can share everything and possibly share
    some money, considering that 230Vac and 12Vac buzzers are similar in price.


    Moreover the push-button for the doorbell is identical to the one used
    to switch on a lamp. It's not uncommon to have a 230Vac frame with
    push-button for doorbell, push-button to activate outdoor lamps and a
    RFID reader to disable the anti-burglar system. All these three elements
    in a frame like this.

    You put your outside lights on an outside switch? Doesn't happen here, at least not at the front door.


    [1] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png

    Your photo looks like an indoor switch. Outdoor switches are typically much more robust and sealed from the elements. Which one is the doorbell switch? Or is all this inside the front door and a visitor opens the door to ring the bell?

    I was thinking to a typical situation here, an apartment in a
    condominium, a bigger multi-houses building. Your doorbell pushbutton is inside the building and you often need to switch on a lamp.


    [1] https://amzn.eu/d/8iPOXgt
    [2] https://amzn.eu/d/b31Lcre
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Tue May 9 17:08:02 2023
    From Newsgroup: comp.arch.embedded

    Il 08/05/2023 21:09, Grant Edwards ha scritto:
    On 2023-05-08, pozz <pozzugno@gmail.com> wrote:
    Il 08/05/2023 16:12, Grant Edwards ha scritto:
    On 2023-05-08, pozz <pozzugno@gmail.com> wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:

    I don't know about where you live, but doorbells in the US are
    powered from low voltage, so they don't require all the safety
    precautions.

    So you have a dedicated power supply for doorbells?

    Yes. A small transformer that costs a couple dollars. It allows use of
    far cheaper wiring and switches than would be required for 120V and
    avoids requirements for approved junction boxes, etc.

    I understand a small transformer is cheap, but anyway it's cheaper and
    simpler not having it at all.

    It's hard to see how the installed cost could cheaper. Using 16V
    allows use of much cheaper wire, you don't need to install junction
    boxes or conduit, the routing requirements for mains voltages don't
    apply, and you don't need a certified electrician to do the work.

    Yes, of course. Anyway, most of the time the doorbell is installed by
    the certified electrician during a renovation or during construction of
    a new building. In this case, you already have a lot of cables and you
    can share already present conduits and junction boxes.


    Here cables for doorbells are routed together with other cables, for
    example for lightning, so they uses the same junction boxes.

    There's a junction box on the outside of the house for light switches?

    Only the frame for push-buttons. Junction boxes are inside the house. On
    the floor of 2-3 apartments, it could be a junction box for common
    assets, such as common lights, antennas, elevator and so on.


    Moreover the push-button for the doorbell is identical to the one used
    to switch on a lamp. It's not uncommon to have a 230Vac frame with
    push-button for doorbell, push-button to activate outdoor lamps and a
    RFID reader to disable the anti-burglar system. All these three elements
    in a frame like this.

    [1] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png

    Those switches are on the outside of the house and one of them is the doorbell button?

    Outside, not outdoor. Yes, one of this is the pushbutton of the doorbell.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Grant Edwards@invalid@invalid.invalid to comp.arch.embedded on Tue May 9 15:10:57 2023
    From Newsgroup: comp.arch.embedded

    On 2023-05-09, pozz <pozzugno@gmail.com> wrote:

    Is it for outdoor use??? The only items I found were the 12V power
    supply.

    Sorry for misunderstanding. It isn't for outdoor use, it is usually
    installed "out of the door" of the apartment, but inside a
    multi-apartment building. Of course, in isolated building where the
    doorbell switch is really outdoor, you can't use that.

    Ah, OK. we're talking about doorbells for single-family, detached
    houses. There's typically a chime mounted on a wall in a central
    location and one or more buttons (two is very common) wired to that
    chime.

    You're talking about apartment buildings. Here in the US, apartment
    buildings don't use the 16V doorbells we've been describing. They
    usually have buzzer/intercom/remote-door-lock systems that are
    completely different than a "doorbell".

    --
    Grant
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Tue May 9 14:29:57 2023
    From Newsgroup: comp.arch.embedded

    On Tuesday, May 9, 2023 at 10:53:52 AM UTC-4, pozz wrote:
    Il 08/05/2023 20:52, Rick C ha scritto:
    On Monday, May 8, 2023 at 12:29:21 PM UTC-4, pozz wrote:
    Il 08/05/2023 16:32, Rick C ha scritto:
    On Monday, May 8, 2023 at 3:38:15 AM UTC-4, pozz wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:
    On Sunday, May 7, 2023 at 5:17:55 PM UTC-4, pozz wrote:
    Il 05/05/2023 22:16, Grant Edwards ha scritto:
    On 2023-05-05, pozz <pozz...@gmail.com> wrote:

    The critical installations often have cables that gives mains power >>>>>>>> (230Vac) to coils, for example relays or door ring bell.

    People use 230VAC for _doorbells_?!?! Are they trying to wake the dead?

    Here in the US doorbells are usually 16VAC, though 24VAC is also used.
    I've also seen 10VAC and 12VAC mentioned, but I think that's uncommon.
    They are very common here (for example [1]). 230Vac is the common mains
    voltage so the doorbells are connected to mains, through a momentary >>>>>> switch out of the door.

    [1] https://comenzielectrice.ro/pdf/Bticino%20-%20Matix%20Catalog.pdf >>>>>> Search for AM5048

    I don't know about where you live, but doorbells in the US are powered from low voltage, so they don't require all the safety precautions.
    So you have a dedicated power supply for doorbells?

    LOL, when you say "dedicated power supply", you mean this.

    https://www.amazon.com/HQRP-Transformer-Compatible-8v-16v-24v-Replacement/dp/B094DKV9NQ
    The price on this link is 23 euros, I think a 230Vac doorbell costs less.

    Yeah, Amazon is often the highest price for various items. The transformer is as little as $8 in local stores.


    The high voltage side of the transformer is mounted on a proper high voltage box. The rest of the wiring is low voltage, so requires no particular safety precautions. The power is low, so even at the low voltage the wire is not heavy, typically 20 or 22 gauge.
    Here they usually route the doorbell 230Vac cables together with other
    cable of electrical system (lightning...) using the same junction boxes.

    "Routing" typically needs no boxes. You still need a box for the button and for the bell. I'm sure you are not grasping the simplicity of a low voltage doorbell.
    I don't want to defend installations that THEY do here where I live. I'm just describing what usually happens.

    In the apartment there are already "in-wall" tubes and junction boxes
    for mains distribution and frames for lights switches. In this case, I
    think it's worth it to "waste" one module to install a 230Vac buzzer
    inside and one module to install a 230Vac pushbutton to activate the
    buzzer outside. During installation of mains circuits you already have 230Vac cables and you can use them for doorbell too.
    I haven't seen you post anything that would be used outside. Worse, you have not explained why there would be a gang switch box outside where the doorbell button would be. Others have asked the same thing, and as far as I can tell, you ignore them as well.
    The prices of 230Vac and 12Vac doorbells are similar (see [1] and [2]),
    You are picking one line item from a single catalog. Price out all the parts required.
    with the plus you can avoid an additional power supply/transformer, even
    if it is cheap.
    I don't know what you are talking about. Sorry. You seem to be addressing doorbells with buttons inside your house. We just don't have much of that in the US.
    Here 99% of house
    doorbells are 230Vac. The installation is much more easy, because you >>>> use directly the mains cables without additional hw.

    Doesn't the button require a much more substantial mounting, as well as the bell itself? That's what the low voltage is avoiding. I think my transformer is mounted in the pantry ceiling not unlike a lightbulb (which is also in the pantry ceiling).
    See [1]. That is a 3-modules frame that can be installed in the wall.
    It's already compatible with 230Vac push-buttons. With one of this you
    can have the push-button for an outdoor lamp, a push-button for the
    doorbell and a keytag reader for anti-burglar system (for example).

    Is it for outdoor use??? The only items I found were the 12V power supply.
    Sorry for misunderstanding. It isn't for outdoor use, it is usually installed "out of the door" of the apartment, but inside a
    multi-apartment building.
    Of course, in isolated building where the doorbell switch is really
    outdoor, you can't use that.
    Yeah, that makes more sense. In the US, older apartments that were made from a single family dwelling, have a number of low voltage buttons on the outside of the main door, or just inside in a foyer. More modern apartments have no doorbells.
    You just knock on the doors. Works pretty well. We have these things called, "knockers".
    You don't need an additional substantial mounting dedicated for doorbell >> pushbutton.

    I have no idea what you are describing. No one I've ever known has high voltage light switches mounted next to the front door with or without a bell button. In fact, it's not allowed to mix low voltage and high voltage in the same box.
    When the apartment is one of many in a building (condominium), there's usually a public light on the common part of the floor (balcony?
    landing?) inside the building. And you could want to switch on when you
    are outside your apartment. Both the light button and doorbell button
    are 230Vac, so no mixing.
    Even in such apartments, we just use low voltage doorbells for all the reasons that have been explained to you. Every part of the system is a lower cost than a 240V bell system. It requires no special consideration for the wiring and can be done by the kid next door, rather than under supervision of a licensed electrician. I don't know why you can't understand this simple matter.
    The pushbutton that activates the doorbells are a normal button (but >>>> momentary) that could be used to activate lights in the room.

    I don't know what that means "normal". Here, all wiring junctions or terminations must be done in an approved box.
    Yes, of course. The same box used for a switch that turns on a light.
    There's no need to add a dedicated box for doorbell.

    You keep saying that, but you have to put in an unsightly and obtrusive high voltage box, next to your front door. If you want to put other high voltage switches in that, fine, but it doesn't change the need for the high voltage box for the doorbell button.
    I don't think this[3] is worse than this[4]. Of course, it depends on personal taste.
    Sorry, I don't know what 3 and 4 are.
    https://www.youtube.com/watch?v=6GUODvOVz10

    The wire junctions shown here are valid, but not common in the US. Mostly people are used to "wire nuts", which are like this, and work well.

    https://www.cableorganizer.com/categories/electrical-supplies/cable-termination/tan-wire-connector/

    The mistake that is often made when using them, is to not twist the wires together before twisting the nut on. The nut is not intended to be a mechanical connection, just electrical. So the insulated portion of the wire should be twisted together first.


    A device on a high voltage circuit has to be mounted on a box or has to be a box rated for such wiring. A door bell uses much simpler wiring and needs no special boxes or precautions. I have seen no small number of doorbell buttons mounted directly in the door frame, having been drilled out to 1/2 inch for mounting the button.

    In the past, the doorbells were dedicated box mounted on the wall, near >>>> the door, inside the apartment.

    Now they tend to install as a module inside push-button frames that are >>>> "inside" the wall ([1] just as an example).

    Anyway my board is not near the buzzer, but could be near the pushbutton
    that activates the buzzer.

    [1]
    https://www.rmelectric.it/3054-large_default/ronzatore-vimar-plana-230v-bianco-suoneria-campanello-segnalatore-acustico-14378.jpg

    The bell itself is not an issue. The PITA is the button.

    https://www.amazon.com/doorbell-push-button/s?k=doorbell+push+button

    These are much easier to mount where they are most convenient. See the small button with the screw terminals? Below is a crude video of a similar button showing the minimal requirements for installation. This guy is upgrading to a video doorbell.

    https://www.google.com/search?q=round+doorbell+button+mounting&client=firefox-b-1-d&sxsrf=APwXEdfIYgYKthf4KothWTYEIfsvEMSPHg:1683555901893&source=lnms&tbm=vid&sa=X&ved=2ahUKEwj2l_e79uX-AhXaMVkFHVUuBuUQ0pQJegQIMBAG&biw=923&bih=497&dpr=1.94#fpstate=ive&vld=cid:1132e9ee,vid:N0H1jSUySH0

    Much simpler and less expensive than running high voltage wiring to the button.
    If you have only a doorbell pushbutton outdoor, yes it could be simpler. >> However here usually installs a "normal" in-the-wall 3-modules box, so
    you can have multiples commodities: doorbell push-button, button for a
    light and so on. This box is already compatible for 230Vac signals.
    I'm wondering if your doorbell has the low voltage transformer inside and the wire to your doorbell is also low voltage? It just makes zero sense to run high voltage to the button.

    [1] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png

    Why do you keep showing pictures of indoor switches? This has nothing to do with the outside doorbell button.
    See above for the misunderstanding.
    I did find this in your catalog.

    bronze bell 12 Va.c. - 5 VA - 80 dB
    Yes, I never said there aren't low voltage buzzers, but they aren't frequently used here.
    Apparently where you live, no one goes outside. All front doors are inside. Nice world.
    --
    Rick C.
    -++- Get 1,000 miles of free Supercharging
    -++- Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rick C@gnuarm.deletethisbit@gmail.com to comp.arch.embedded on Tue May 9 14:32:59 2023
    From Newsgroup: comp.arch.embedded

    On Tuesday, May 9, 2023 at 11:06:29 AM UTC-4, pozz wrote:
    Il 08/05/2023 20:39, Rick C ha scritto:
    On Monday, May 8, 2023 at 12:15:19 PM UTC-4, pozz wrote:
    Il 08/05/2023 16:12, Grant Edwards ha scritto:
    On 2023-05-08, pozz <pozz...@gmail.com> wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:

    I don't know about where you live, but doorbells in the US are
    powered from low voltage, so they don't require all the safety
    precautions.

    So you have a dedicated power supply for doorbells?

    Yes. A small transformer that costs a couple dollars. It allows use of >>> far cheaper wiring and switches than would be required for 120V and
    avoids requirements for approved junction boxes, etc.
    I understand a small transformer is cheap, but anyway it's cheaper and
    simpler not having it at all.

    LOL You don't seem to understand. You either have the transformer as a separate entity, or its functionality is incorporated in something more expensive, because it is rated for 240V.
    See [1] and [2]. The prices are the same.
    Here cables for doorbells are routed together with other cables, for
    example for lightning, so they uses the same junction boxes.

    I think you mean "lighting".
    Yes, sorry.
    But you can't lump the doorbell with anything else. At least not in existing construction. It is all irrelevant. Do what you wish. Spend the money on 240V wiring at a dollar a foot and high voltage boxes. That's your choice. But the fact is, the low voltage doorbell is much cheaper to install.
    I don't want to spend any money for any doorbells ;-)
    This is what I see, I'm not an expert of mains distribution in buildings
    and apartments.

    I'm only supposing that in a new house, where you already have 230Vac
    tubes and junction boxes and you need one or more light push-buttons out
    of the door (not outdoor), you can share everything and possibly share
    some money, considering that 230Vac and 12Vac buzzers are similar in price.
    You literally know nothing of the issues of wiring high voltage vs. low voltage. You keep talking about the buttons in a catalog, without understanding how they are used. I can't spend any more time trying to explain it to you. So, you may hold your ideas dear.
    Moreover the push-button for the doorbell is identical to the one used
    to switch on a lamp. It's not uncommon to have a 230Vac frame with
    push-button for doorbell, push-button to activate outdoor lamps and a
    RFID reader to disable the anti-burglar system. All these three elements >> in a frame like this.

    You put your outside lights on an outside switch? Doesn't happen here, at least not at the front door.


    [1] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png

    Your photo looks like an indoor switch. Outdoor switches are typically much more robust and sealed from the elements. Which one is the doorbell switch? Or is all this inside the front door and a visitor opens the door to ring the bell?
    I was thinking to a typical situation here, an apartment in a
    condominium, a bigger multi-houses building. Your doorbell pushbutton is inside the building and you often need to switch on a lamp.
    [1] https://amzn.eu/d/8iPOXgt
    [2] https://amzn.eu/d/b31Lcre
    Ok, Enjoy.
    --
    Rick C.
    -+++ Get 1,000 miles of free Supercharging
    -+++ Tesla referral code - https://ts.la/richard11209
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pozz@pozzugno@gmail.com to comp.arch.embedded on Wed May 10 08:55:57 2023
    From Newsgroup: comp.arch.embedded

    Il 09/05/2023 23:32, Rick C ha scritto:
    On Tuesday, May 9, 2023 at 11:06:29 AM UTC-4, pozz wrote:
    Il 08/05/2023 20:39, Rick C ha scritto:
    On Monday, May 8, 2023 at 12:15:19 PM UTC-4, pozz wrote:
    Il 08/05/2023 16:12, Grant Edwards ha scritto:
    On 2023-05-08, pozz <pozz...@gmail.com> wrote:
    Il 07/05/2023 23:27, Rick C ha scritto:

    I don't know about where you live, but doorbells in the US are
    powered from low voltage, so they don't require all the safety
    precautions.

    So you have a dedicated power supply for doorbells?

    Yes. A small transformer that costs a couple dollars. It allows use of >>>>> far cheaper wiring and switches than would be required for 120V and
    avoids requirements for approved junction boxes, etc.
    I understand a small transformer is cheap, but anyway it's cheaper and >>>> simpler not having it at all.

    LOL You don't seem to understand. You either have the transformer as a separate entity, or its functionality is incorporated in something more expensive, because it is rated for 240V.
    See [1] and [2]. The prices are the same.
    Here cables for doorbells are routed together with other cables, for
    example for lightning, so they uses the same junction boxes.

    I think you mean "lighting".
    Yes, sorry.
    But you can't lump the doorbell with anything else. At least not in existing construction. It is all irrelevant. Do what you wish. Spend the money on 240V wiring at a dollar a foot and high voltage boxes. That's your choice. But the fact is, the low voltage doorbell is much cheaper to install.
    I don't want to spend any money for any doorbells ;-)
    This is what I see, I'm not an expert of mains distribution in buildings
    and apartments.

    I'm only supposing that in a new house, where you already have 230Vac
    tubes and junction boxes and you need one or more light push-buttons out
    of the door (not outdoor), you can share everything and possibly share
    some money, considering that 230Vac and 12Vac buzzers are similar in price.

    You literally know nothing of the issues of wiring high voltage vs. low voltage. You keep talking about the buttons in a catalog, without understanding how they are used. I can't spend any more time trying to explain it to you. So, you may hold your ideas dear.

    I don't know how we are fighting for this kind of arguments. I don't
    want to convince you, I'm not a professinal electrician and for me is
    good what you write. Keep on with embedded things.


    Moreover the push-button for the doorbell is identical to the one used >>>> to switch on a lamp. It's not uncommon to have a 230Vac frame with
    push-button for doorbell, push-button to activate outdoor lamps and a
    RFID reader to disable the anti-burglar system. All these three elements >>>> in a frame like this.

    You put your outside lights on an outside switch? Doesn't happen here, at least not at the front door.


    [1] https://i.ebayimg.com/images/g/1q0AAOSw7Wtd4lsd/s-l1600.png

    Your photo looks like an indoor switch. Outdoor switches are typically much more robust and sealed from the elements. Which one is the doorbell switch? Or is all this inside the front door and a visitor opens the door to ring the bell?
    I was thinking to a typical situation here, an apartment in a
    condominium, a bigger multi-houses building. Your doorbell pushbutton is
    inside the building and you often need to switch on a lamp.
    [1] https://amzn.eu/d/8iPOXgt
    [2] https://amzn.eu/d/b31Lcre

    Ok, Enjoy.


    --- Synchronet 3.20a-Linux NewsLink 1.114