jonsmirl's blog

Intellon White Paper on how powerline broadband works

If you are interested in the technical details of how powerline broadband modems work the paper linked below provides a nice overview. We're using the 85Mb PHY version which really means about 30Mb of useful bandwidth. We considered the 200Mb version (65Mb useful) but we don't think it is worth the added cost for our application. The only time you'll notice the peak network speed is when you are copying music to the nodes. Once the music is in the nodes there is plenty of bandwidth available to play it.

The bandwidth of powerline modems is shared with your neighbors on the same power transformer, usually not more than five homes. This could potentially be a problem that will be examined with field testing. The load caused by bulk copying to the nodes can be controlled using QOS. We don't think the shared medium will matter since music doesn't need a lot of bandwidth to play.

Intellon HomePlug AV White Paper

Sample powerline modem

Homeplug uses the same OFDM modulation as 802.11 wireless. The Intellon chips contain dedicated hardware for doing real-time FFTs of the powerline signal. The actually circuitry is not that complicated. Here's a picture of an older 14Mb Homeplug device. The circuitry is very similar for 85Mb. The long back thing at the bottom of the photo has been replaced with an analog chip from Intellon.

Another good thing going into the kernel

The Linux kernel is finally getting real support for SD cards.
http://kerneltrap.org/Linux/MMC_Flash_Memory_Card_Support

Pierre went on to discuss the Serial Peripheral Interface (SPI) stack, "the second large feature is the fact that you can now use your SPI controllers for MMC, SD and SDIO. Yes, even SDIO works nicely over SPI. This means that a lot more systems can get storage and expansion I/O at basically the cost of a connector."

This is good for Digispeaker since we have an SD Card hooked up with SPI. Now we have a device driver for it!

Compared to this my problems are minor

"I'm pleased to announce another release of Squashfs. This is the 22nd release in just over five years. Squashfs 3.3 has lots of nice improvements, both to the filesystem itself (bigger blocks and sparse files), but also to the Squashfs-tools Mksquashfs and Unsquashfs," stated Phillip Lougher.

Squash developers are focused next on getting squash into the mainline kernel.
http://kerneltrap.org/Linux/Squashfs_Aiming_For_Mainline_Kernel

22 revisions and five years. I've only been working on getting the Digispeaker patches in for about a month.

Good thing squash is going in, we use it for our root flash file system.

Getting code into the Linux kernel

Digispeaker is based on open source software. The main operating system is the Linux kernel running on the PowerPC MPC5200B. My past kernel programming projects have all been based on x86 hardware so I'm learning a lot about how things are done on the PowerPC. Instead of a BIOS like x86 machines, the PowerPC uses a standard called Open Firmware. Open Firmware contains a device tree language for describing the hardware layout of a particular PowerPC based design. Here's a small section of a device tree description:

i2c@3d40 {

compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";

reg = <3d40 40>;

interrupts = <2 10 0>;

interrupt-parent = <&mpc5200_pic>;

rtc@51 {

compatible = "epson,rtc8564";

reg = <51>;
};

codec@27 {

compatible = "ti,tas5504";

reg = <27>;
};

};

This section describes the i2c controller. The i2c controller implements a bus. The rtc and codec are attached to this bus.

I'm implementing code for supporting this syntax of describe the i2c devices as children of the i2c bus in the device tree. Reading this email thread will give you an idea of what needs to be done to get code into the Linux kernel.

Syndicate content