On Mon, 30 Nov 2015 03:24:39 +0200, Dimiter_Popoff <dp@tgi-sci.com> wrote:>>>>> I am not familiar with CAN but I would like to see a standardized >>>>> Ethernet connector for coaxial cable plus power pins (12V?). Have been >>>>> dreaming of that for may be 25 years. >> >> The 10Base5 with vampire taps and RG-8 like coaxial cable was nice, >> why not implement your own PoE ? The RG-8/213 like coaxial cable can >> withstand several hundred volts and several amps :-) > >I would if I felt I had the muscle to enforce a standard :). >It does not have to be 10base5, 10base2 (not sure, the 5mm coax >cable thing) is plenty I think. I am not thinking hundreds of meters, >rather a few meters to may be tens of meters.10base2 (RG-58) cable can only handle 300 Vdc and will melt at around 10 A, so the available power would be well below 3000 W :-)>Then may be today >we can do somewhat more than 10 Mbps over the coax cable, say 50 >would be very nice.Any DMT/OFDM system can carry much more than that. For instance DVB-C2 used by some CATV companies and MATV systems can carry at least 10 Gbit/s on a single coaxial cable with up to 12 bits/symbol, at least 850 MHz, potentially 2 GHz bandwidth. Of course DVB-C2 is highly complex.>Using a <3mm coax (I always have to look up the >RG whatever names...) could also be convenient within say an apartment >or a small house.RG-174 might be carrying several Gbit/s at those distances using some sort of DMT/OFDM.
CANBUS Tx/Rx with data length > 8 bytes
Started by ●November 19, 2015
Reply by ●December 4, 20152015-12-04
Reply by ●December 4, 20152015-12-04
Am 04.12.2015 um 11:04 schrieb Dimiter_Popoff:> How did you handle what I described in my initial message? The > "unidirectional" aspect of it I mean (don't know what else to call it, > the fact that the master can't know whether the slave had data to send > and that the slave has no way of knowing whether the master is clocking > in valid data or just clocking it to poll it for output)?The obvious choice would be to just stop worrying about it, because it's not actually an issue. Both problems go away once you realize that there's not actually any hurt in just sending the same data again if the originating node has nothing newer available. Yes, that will mean you waste some of the bandwidth on needless repeats, but then again, SPI is generally pretty fast to begin with, so a little waste should be tolerable.
Reply by ●December 5, 20152015-12-05
On 04.12.2015 г. 23:26, Hans-Bernhard Bröker wrote:> Am 04.12.2015 um 11:04 schrieb Dimiter_Popoff: > >> How did you handle what I described in my initial message? The >> "unidirectional" aspect of it I mean (don't know what else to call it, >> the fact that the master can't know whether the slave had data to send >> and that the slave has no way of knowing whether the master is clocking >> in valid data or just clocking it to poll it for output)? > > The obvious choice would be to just stop worrying about it, because it's > not actually an issue. Both problems go away once you realize that > there's not actually any hurt in just sending the same data again if the > originating node has nothing newer available. Yes, that will mean you > waste some of the bandwidth on needless repeats, but then again, SPI is > generally pretty fast to begin with, so a little waste should be tolerable.No, this just does not work. Please try to _understand_ my initial post. Dimiter
Reply by ●December 5, 20152015-12-05
On 04.12.2015 г. 21:49, upsidedown@downunder.com wrote:> On Mon, 30 Nov 2015 03:24:39 +0200, Dimiter_Popoff <dp@tgi-sci.com> > wrote: > >>>>>> I am not familiar with CAN but I would like to see a standardized >>>>>> Ethernet connector for coaxial cable plus power pins (12V?). Have been >>>>>> dreaming of that for may be 25 years. >>> >>> The 10Base5 with vampire taps and RG-8 like coaxial cable was nice, >>> why not implement your own PoE ? The RG-8/213 like coaxial cable can >>> withstand several hundred volts and several amps :-) >> >> I would if I felt I had the muscle to enforce a standard :). >> It does not have to be 10base5, 10base2 (not sure, the 5mm coax >> cable thing) is plenty I think. I am not thinking hundreds of meters, >> rather a few meters to may be tens of meters. > > 10base2 (RG-58) cable can only handle 300 Vdc and will melt at around > 10 A, so the available power would be well below 3000 W :-)Hmmm, so we'll have to use separate cabling to heat larger rooms during the cold winter days (no such issue down under I suppose :D ).> >> Then may be today >> we can do somewhat more than 10 Mbps over the coax cable, say 50 >> would be very nice. > > Any DMT/OFDM system can carry much more than that. For instance DVB-C2 > used by some CATV companies and MATV systems can carry at least 10 > Gbit/s on a single coaxial cable with up to 12 bits/symbol, at least > 850 MHz, potentially 2 GHz bandwidth. Of course DVB-C2 is highly > complex. > >> Using a <3mm coax (I always have to look up the >> RG whatever names...) could also be convenient within say an apartment >> or a small house. > > RG-174 might be carrying several Gbit/s at those distances using some > sort of DMT/OFDM. >My first thought re your suggested cable modem techniques was "too complex". Well complex of course, but perhaps not "too complex" nowadays, I would bet cable modems are single chip units nowadays (actually I opened one some 5-10 years ago and it had some BGA plus some small stuff, IIRC the radio part was at least in part discrete). But my thoughts on that revolve around misusing the RG-174 in the good old 10 Mbps manner, say 50 Mbps should be easily doable nowadays. Hopefully the PHY will not need these -9 volts... but keeping it galvanically isolated makes that irrelevant really. I would also vote for a version with no galvanic isolation, say for use within the same room, many people torture i2c at longer distances to connect a sensor etc., this could make things easier and more robust if doable cheap enough. And will be a source of countless torn hairs for people who will inevitably push it to and beyond its limits.... :D . Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
