Yes, i guess they would do the trick. Our Pi was also powered by the cable and had a button to interrupt the power to trigger a reboot (ie. upload another image and run it)
Somebody forked an OS-X version though. The code is quite simple and might be easy to port/rewrite for windows... (Just wait for an escape sequence then upload the image, AFAIR)
Would cygwin do the trick?
I'm not sure about your setup but what about USBoverIP? Something like:
I just keep assuming you are using microsoft windows. i fired up a windows vm, installed cygwin (with gcc/g++) and could build raspbootcom. Raspbootcom is runnable but I don't have the stuff available here to go any further.
Technically, 90m is not an upper limit for ethernet as such - just for ethernet over Cat5(e) twisted-pair cable, when used as
10/100/1000BASE-T. 10BASE2 ('thin ethernet') coaxial cable (usually RG-58) has a maximal segment length of about 185m, 10BASE5 ('thick ethernet', usually RG-8) has a max segment length of about 500m.
;)
But even for RS-232, there's no lengthlimit specified as such; Wikipedia claims,
The standard does not define a maximum cable length but instead defines the maximum capacitance that a compliant drive circuit must tolerate. A widely used rule of thumb indicates that cables more than 50 feet (15 m) long will have too much capacitance, unless special cables are used. By using low-capacitance cables, full speed communication can be maintained over larger distances up to about 1,000 feet (300 m).
It's not that simple. Line drivers would cost money and might require a reduced baud rate.
As an aside line drivers in a work environment had a high TCO because they were unmanaged and thus invisible. If we lost contact between managed comms devices which were separated by just a single pair of line drivers there were about seven places where the fault could be costing downtime and engineer time to address. I would not recommend unmanaged comms devices.
A better investment might be to set up a separate Unix server by buying another Pi!
As always, it is not that simple. As usual with "managed" and "redundant" solutions, there is a higher initial failure rate because of the increased complexity of the product. You have to hope that the quicker diagnosis or the capability to enable redundant paths prevents more outages than the complexity of the system adds.
In practice, that often is not clear. I have seen such complex systems fail where simple unmanaged devices kept working and working and working...
In article , snipped-for-privacy@bobby.df.lth.se says... ....
That old urban myth based on misinterpretation on testing comments with I believe RS232-B spec, where someone comment about a fully loaded V24 set (25 way D on modem), using RS232 signally the noise came up due to cable capacitance at 15m.
What everyone forgot to check was
a) This was poor cable type and unshielded
b) The noise was still WELL within spec
c) There was no data or signalling loss
Have seen RS232 been driven down a couple of kms of bell wire, only one pair, and on a drum, but it can go long distances. Having worked in days were large offices had RS232 runs to loads of terminals around the buildings, the cable runs in a lot of cases were well over 50m. Mind you
38400baud was a rarity, 9600 and 19k2 were the norm for HIGH speed.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Raspberry Pi Add-ons
Timing Diagram Font
For those web sites you hate
In my experience, using "shielded cable" or "data cable" actually made things worse. Of course this is to be expected, that cable has more capacitance per meter than telephony twisted pair.
We always used telephony cable to make RS232 cables.
It's worth remembering that digital communications predates analogue by about a century (think telegraph versus telephone). The initial methodology of sending morse signals was the simplest method possible (on off keying of current in a long single overhead line using earth return, essentially the system used by the com ports on a PC or simple I/O connections on a RasPi).
The problem with this was that the unipolar current used was at the mercy of capacitive effects which distorted the shape of the pulses recieved at the distant end of the line. The simple workaround to this problem was to use reduced signalling speeds (exactly the same strategy used by similarly simple com port connections, trading off the baud rate against line length).
The early telegraphs then started using bi-polar signalling to compensate for the effects of cable distortion. Effectively cancelling out the capacitive effect on waveshape making the trade off on increasing line length a matter of increased attenuation only which could be gotten round by using repeater relays (virtually no build up of distortion to contend with).
Also, it was swiftly appreciated that running a seperate return wire provided much better immunity to electrical interference (initially QRN only but eventually QRM as well). This evolved into balanced line working which was required on routes with several telegraph circuits running in parallel (usually on telegraph poles trackside of railway networks).
The modern day computer equivilent is the use of bi-polar line drivers (balanced or not) and regenerators to extend the reach of such serial data lines. As in the case of telegraphy you can trade off baud rate for distance over non balanced lines.
In the case of bi-polar driven balanced lines and balanced recievers, there's very little trade off effect between baud rate and (unregenerated) line length, you'll just reach a point where the signal becomes too attenuated to be reliably detected at any baud rate.
Baud rate will only make a difference when the line length is just at the limit for the cable type employed. When the reciever impedance is matched to the cable impedance, it may be possible to still send reliably when a much reduced baud rate is chosen.
When the reciever impedance is deliberately mismatched (Hi-Z) to magnify the voltage pulses at the reciever, only certain baud rates may work over lines extended by this mismatch artifice. The normal practice is to use lo-Z transmitters driving lines terminated by a matched impedance load.
The use of deliberate mismatching to take advantage of voltage magnification is usually restricted to memory buses using clock rates of hundreds of MHz, mainly to speed up the signals rather than extend the bus length.
If you want to extend the line length of a serial port connection without adding active regenerator boxes, you either reduce the baud rate or employ a more expensive lower loss cable for the run.
For longer circuits, building to building runs of a few hundred metres, you'd use balanced line drivers with higher voltages, typically 12 to 24 volt bi-polar supplies.
It's worth keeping in mind that GPO baseband telegraphy stations (teleprinter circuits) used two 80v station batteries to supply both positive and negative battery voltages for signalling purposes over the trunk lines linking each station as well as the local circuits into each subscribers' premises. A practice that was still in common use at the end of the sixties.
They were already multiplexing signals on audio carriers in telephone cables by the mid sixties and, at a guess[1], probably replaced most dedicated subscriber telegraph circuits with modem equipped phone lines by the early seventies.
[1] I'm guessing because I wasn't involved with telegraphic station work by that time.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.