Reverse engineering a cable modem and turning it into an SDR | Hacker News Reader

Reverse engineering a cable modem and turning it into an SDR

stdw.github.io

155 pointspabs340 comments

"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.

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)

You meant average, not sum, right?

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.

Averaging is a FIR filter

>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...

Maybe it is better to just replace it by something existing but more advanced. Ethernet, for instance.

Ethernet PHY is way more complicated & costly than a small handful of TTL GPIOs...

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.

(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.

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.

what sort of compatibility does RS-232 doesn't represent if not electrical or logical?

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.

FWIW, some Panasonic laptops still have real (non-USB, as opposed to their internally-USB-based) RS-232 ports. Just saying...

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.

I'll bet many of those implementations are SLIP Serial link IP.

Yup, if it was built in the mid 2010s or later I'll see that, but most of the machines I've worked with have been running since the 90s. Still running Windows XP etc.

Occasionally, but usually it's simpler protocols like Modbus running over serial.

Industrial or automotive communication is over long distances in hostile environments (as was RS-232, arguably). This is just for short logic-level comms to a debug port on a board.

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.

Agreed, my suggestion is just to make that simple protocol self-clocking (which is simple to do) so you eliminate the strict yet unknowable timing requirement of “UART protocol” (I don’t know a better name for the logical protocol underlying RS-232).

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.

To be clear, this doesn’t currently exist, but the premise was that everyone agrees to switch to something else. (Which is an unlikely premise, but maybe if something got momentum…)

Microcontrollers do have their own proprietary serial debug protocols. ARM SWD, for example, has been around for almost 15 years. It’s “proprietary”, but being ARM that means it’s in billions of chips from many manufacturers. It does require a clock line, though.

https://www.ti.com/lit/wp/spmy004/spmy004.pdf

I’m suggesting something much simpler though, just keep the UARTs and stick a Manchester encoder/decoder in between.

Funny, I always thought that going over 38400 without flow control was unstable. Times have changed I guess.

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/

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.

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.

eCos! It also ran Sinar emotion digital backs

As someone with two cable modems sitting around gathering dust, this piqued my interest. Looks like this project never really took off though.

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.

Futile wish. Even if you controlled the modem entirely the "other side" can do whatever they want with your packets.

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

I mean you can already do normal ethernet over coax if it's all you have in your building, thanks to MoCa.

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.

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"

Fascinating hacking work. I adore this article especially because at each step, it explains the reasoning behind it. Comes just at the right time, as I'm studying electrical engineering.

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).

Wouldn't an old tv tuner chip work better for this? It's what RTL-SDR uses...

This is awesome

> 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.

Reply on news.ycombinator.com