[HN Gopher] Reverse engineering a cable modem and turning it int...
___________________________________________________________________
Reverse engineering a cable modem and turning it into an SDR
Author : pabs3
Score : 129 points
Date : 2024-03-06 03:20 UTC (19 hours ago)
(HTM) web link (stdw.github.io)
(TXT) w3m dump (stdw.github.io)
| pajko wrote:
| "alone did not improve the performance much, but by only taking
| every Nth sample, I could lower the effective sample rate,
| shorten the processing time, and reduce the number of bytes I had
| to send back which greatly improved the latency."
|
| Right, the latency would improve but with the cost of increased
| uncontrolled noise. An anti-aliasing filter shall be applied
| before the decimation to overcome that.
|
| IIR filters are out of the question for this purpose because of
| how the phase is affected.
|
| FIR filters tend to be costy due to a possibly high order. Proper
| decimating filters reduce that cost by a factor of N. Also if
| it's not required to keep full Fs/2N bandwidth clean just a part
| of it, it's enough to just "punch holes" instead of doing a full
| lowpass, which reduces the cost further.
| mikewarot wrote:
| If you have too many samples to send down the wire, but DO have
| enough CPU left to do the math... just sum the samples to bin
| them before sending them down the wire, you'll lower the sample
| rate, and slightly improve the signal to noise ratio in the
| process (while also low pass filtering it)
| blashyrk wrote:
| You meant average, not sum, right?
| mikewarot wrote:
| No, I meant sum.... assuming all of the samples are integer
| values, and you have enough bits in the sum, you don't risk
| overflow, and gain a bit of dynamic range in the process.
| pajko wrote:
| Averaging is a FIR filter
| tetris11 wrote:
| This is really impressive. I yearn for a day where there will be
| open source DOCSIS 3 compatible modems out there.
|
| It grates me that the only solution I have to open networking is
| to put my modem into an open router and hope that no shenanigans
| are happening in the modem.
| adql wrote:
| Futile wish. Even if you controlled the modem entirely the
| "other side" can do whatever they want with your packets.
| dec0dedab0de wrote:
| what if you had both sides? I could see this being useful in
| a building/complex that already has coax, or as a way to
| cheaply do longer distances while keeping hardware out of a
| landfill
| bcx5k15 wrote:
| I mean you can already do normal ethernet over coax if it's
| all you have in your building, thanks to MoCa.
| gorkish wrote:
| You can get CMTS equipment like Arris C3 and run your own
| DOCSIS headend if you want, but it's a lot of complexity to
| the point where it's not worth the effort unless it just
| happens to exactly fit your niche. Due to the way that
| cable plants work (upstream channels) the 'provider side'
| equipment must be complimentary to the 'customer side'
| equipment. That is there is no method for peer-to-peer
| traffic between cable modems in the DOCSIS standard even if
| the hardware is theoretically capable.
|
| OTOH you can get a 2.5gbps MoCA adapter for like 50 bucks,
| and it can be installed, working, and reasonably secure in
| about 30 seconds. So I don't think DIY DOCSIS is a
| worthwhile pursuit outside the novelty.
| transpute wrote:
| _> I say if you have the skills, time and desire, give it a go
| and see where you end up. If google shows nothing, then its
| likely not been tried. With so few firsts available in life, take
| those that present themselves and have a crack, even if failure
| is always an option. --VK4HAT_
|
| Timeless quote.
| roger_ wrote:
| As someone with two cable modems sitting around gathering dust,
| this piqued my interest. Looks like this project never really
| took off though.
| gorkish wrote:
| The Hermes-Lite [1] SDR is a direct sampling HF QRP transceiver
| that uses a cable modem IC to do the dirty work. It has been out
| for years, is 100% open source hardware and firmware/gateware,
| and works great!
|
| [1] http://www.hermeslite.com/
| 1970-01-01 wrote:
| >The baud rate was a lucky guess, but 115200 is very common on
| such devices.
|
| This is a 40 year old problem that has no solution. All we would
| need to do is agree on exactly how to do it and set it as a
| standard.
|
| https://www.eevblog.com/forum/microcontrollers/smart-auto-ba...
| amelius wrote:
| Maybe it is better to just replace it by something existing but
| more advanced. Ethernet, for instance.
| beambot wrote:
| Ethernet PHY is way more complicated & costly than a small
| handful of TTL GPIOs...
| theamk wrote:
| Ethernet is nice, but for low-level debug purposes, it is
| significantly harder to use than UART.
|
| With UART, you have a single integer to guess, maybe one of
| the 10 options. And guessing it simple, as data flows even
| when nothing is connected, so you can trivially find it on
| the PCB and scope it.
|
| With Ethernet, you have vastly more thing to guess. Starting
| with Ethernet pinout, then IP address, then port, protocol
| and authentication. And in most cases, you are not going to
| be able to passively listen and get useful debug information
| - while I can theoretically imagine an embedded system
| configured with netconsole in broadcast mode, I've never seen
| such configuration in practice.
|
| Yes, Ethernet is very nice if device works, but it's pretty
| unusable for embedded / early boot debugging.
| theamk wrote:
| (1) The "standard" is pretty impossible as long as there are
| cheap microcontrollers and USB-UART adapters around. If your
| CPU runs at 4 MHz clock, you simply cannot get 57600 baudrate
| going (without PLL, but 4MHz micro is not going to have it).
| But if you have embedded linux, you want it fast, at least
| 115200, maybe even 230400... But depending on the clock tree,
| your UART clock could be pretty low, so maybe 250000 baud is
| more realistic. But many cheaper adapters have problem with
| high speeds and/or non-standard rates, so if you expect your
| device to be serviced in the field with ad-hoc equipment, maybe
| go down to 57600 just to make sure?
|
| (2) The solution existed for a long time: get a logic analyzer
| or a scope, then look at the signal. This is pretty simple and
| very cheap, as sub-MHz logic analyzers are like $10 today.
|
| (3) That said, last time I had an unknown device I was too lazy
| to find my scope and connect it.. it was much easier to me to
| try a few bitrates using regular UART util output started to
| make sense, especially since it's often easy to tell if the
| bitrate is a bit off or way off.
| wrs wrote:
| Or we could agree to use a self-clocked format (Manchester
| coding or similar) so it wouldn't be necessary to know the rate
| up front. It would go half as fast, but we have 4MHz UARTs
| nowadays so that's no big deal for a console.
|
| Everybody uses a USB dongle now to talk to these things anyway,
| so there's no reason to stay electrically or logically
| compatible with RS-232.
| detourdog wrote:
| what sort of compatibility does RS-232 doesn't represent if
| not electrical or logical?
| wrs wrote:
| I'm saying RS-232 is irrelevant both electrically and
| logically, if you're already assuming people can agree on
| something new. There are lots of better cheap 3-wire logic-
| level serial protocols nowadays. The days when your PC had
| a literal RS-232 port on the back are long gone.
| Rediscover wrote:
| FWIW, some Panasonic laptops still have real (non-USB, as
| opposed to their internally-USB-based) RS-232 ports. Just
| saying...
| bongodongobob wrote:
| Industrial automation would like a word. Seems to be
| slowly moving to TCP/IP but lots and lots use serial
| communication either internally or to the
| HMI/workstation.
| detourdog wrote:
| I'll bet many of those implementations are SLIP Serial
| link IP.
| detourdog wrote:
| What I was trying to express is that a protocol based on
| simple electricity/gates and logic is so simple that it
| almost has to exist and almost all that RS-232 consists
| of.
|
| Many 1-wire are RS-232 implementations over a "1" wire.
|
| I have my eye on Sony 8K TV and it has RS-232.
| theamk wrote:
| Are there?
|
| If I look at a common MCU, my choices are UART, SPI and
| I2C. Out of those, UART is the only interface which can
| easily handle printf-style debug messages without
| additional protocols. I can manage something with SPI or
| I2C in a pinch, but this would be non-standard and
| require special software on PC side. If I really hate
| UART for some reason I can set up SPI master, but this
| will just require 2 extra wires and a very special host
| adapter (all the ones I saw are master-mode).
|
| More expensive micros have CAN and Ethernet. Ethernet is
| nice but needs magnetics, probably overkill for debug
| port; plus once you have Ethernet on-board no one is
| happy with raw frames, so you end up with ARP, DHCP, IP,
| TCP and lots of memory usage. CAN is pretty cool, but
| developer tools are overpriced and very bad, and most
| larger SOCs do not have support for it. Plus you still
| have to select baudrate for it :)
|
| Sadly, there does not seem to be anything "new" people
| could agree too... The combined inertia of billions of
| microcontrollers will keep UART alive forever.
|
| ... but hey, if I were a head of R&D for microcontroller
| company, I'd totally design my own debug protocol. It'd
| be pulse based (to allow random clock rates but also keep
| line quiet when there is no output), potentially
| capacitively coupled (because I hate ground loops), use
| single signal wire + ground (because debug channel does
| not need full duplex), have integrated "packet end" mark
| and predefined packet types for text logs and binary TLV.
| It'd also have fully open debug tools. But I am not
| designing my own chips, so I am just using UART.
| mannyv wrote:
| Funny, I always thought that going over 38400 without flow
| control was unstable. Times have changed I guess.
| bcx wrote:
| I was really hoping this article was going to about how someone
| was able to turn their cable modem into a sales development
| representative (SDR), because of the absurdity :). I was
| pleasantly surprised by the actual article: SDR (software defined
| radio).
| bustling-noose wrote:
| I always assumed cable modems run linux (but its not clear from
| this post if it actually does run linux on its main cpu). Most,
| if not all, PON equipment now runs linux but modems were a
| different type of thing back then. DOCSIS modems were buggy, ran
| really hot and were really just a bad experience overall if you
| lived in a crowded area (because more contention ratio meant more
| problems with signal). The worse the signal, the hotter these ran
| (I am assuming more noise filtering was needed ? I might be
| wrong). If someone can actually get these to do something good
| that would be great. But in general I am glad this is one piece
| of tech that has stopped existing in my area and everyone has
| moved to fiber.
| angiosperm wrote:
| He says it runs eCos, a real-time kernel. And, that the other,
| unused CPU would run Linux on more full-featured products on
| the same hardware base.
| buildbot wrote:
| eCos! It also ran Sinar emotion digital backs
| nubinetwork wrote:
| Wouldn't an old tv tuner chip work better for this? It's what
| RTL-SDR uses...
| araes wrote:
| Apparently got Toto's "Africa" as their radio listening secret
| message.
|
| Appropriately cryptic result for messing with an old cable modem
| and turning it into a software defined radio. I
| stopped an old man along the way Hopin' to find some old
| forgotten words or ancient melodies He turned to me as if
| to say "Hurry, boy, it's waiting there for you"
| mannyv wrote:
| This is awesome
___________________________________________________________________
(page generated 2024-03-06 23:02 UTC)