General > General Technical Chat
Wire over ethernet
PlainName:
That would severely dent what the link could be used for, both in the way of network bandwidth and non-network connections.
Edit: got that wrong - it would give me potentially three wires (I was thinking pairs, but a single return might be fine depending on requirement). But the 100MB network is too horrible to contemplate. Otherwise a good idea!
shapirus:
--- Quote from: PlainName on March 26, 2024, 09:36:46 pm ---Ah, perhaps I wasn't too clear. There is no data rate as such - imagine a button at one end and a button input at the other. Or an LED. Perhaps daylight sensor (analog). Stuff like that - if I need to do actual data comms then I would do that via a pukka IP connection.
--- End quote ---
Ethernet is a digital protocol. If you need to transmit an analog signal using a digital protocol, then you have to digitize it (and convert back to analog, if required, on the receiving side). Once it's digitized, you have data rate and timing requirements.
PlainName:
--- Quote from: shapirus on March 26, 2024, 11:51:25 pm ---
--- Quote from: PlainName on March 26, 2024, 09:36:46 pm ---Ah, perhaps I wasn't too clear. There is no data rate as such - imagine a button at one end and a button input at the other. Or an LED. Perhaps daylight sensor (analog). Stuff like that - if I need to do actual data comms then I would do that via a pukka IP connection.
--- End quote ---
Ethernet is a digital protocol. If you need to transmit an analog signal using a digital protocol, then you have to digitize it (and convert back to analog, if required, on the receiving side). Once it's digitized, you have data rate and timing requirements.
--- End quote ---
Sure, but the rate of change determines how often you need to send data, so if that rate is either slow or steppy then your actual protocol speed can be, er, relaxed. You don't have to do 44kHz x 16-bit when nowt is happening.
shapirus:
--- Quote from: PlainName on March 27, 2024, 12:01:24 am ---Sure, but the rate of change determines how often you need to send data, so if that rate is either slow or steppy then your actual protocol speed can be, er, relaxed. You don't have to do 44kHz x 16-bit when nowt is happening.
--- End quote ---
Well yes, but there is still some data rate and there are still timing requirements to meet. It may be low or high and it may be easy or difficult, depending on the sample rate and sample size of the ADC process. So for analog signals, you basically need ADC->MCU (with an eth interface)->ethernet->MCU->DAC, correct? I don't know if there are any ready made solutions, but it doesn't sound too hard to DIY, as long as bandwidth requirements stay reasonably low. For digital signals, you skip ADC/DAC and use GPIO directly (after/before level conversion and input/output protection, if necessary).
PlainName:
--- Quote --- I don't know if there are any ready made solutions, but it doesn't sound too hard to DIY
--- End quote ---
Well that's is the crux of my original ask: I was going to get started on DIY but then wondered if I would just be reinventing some product that already exists.
The thread has turned up some things to think about. For instance, I hadn't considered the modbus gateways which superficially seem inappropriate because they are slaves oops, clients wanting a controller, but an ESP32-based doobrey could easy be that as well as dealing with it's own I/O. But if I'm going to have one ESP32-based device, why not have that at both ends instead. It is close, but I think it has to be either completely turnkey or all DIY.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version