Teardowns seem to go two ways, there's the industrial side of things where all the components are well marked but are expensive or difficult to get and datasheets are commonly not available to the public. Then there's the consumer side of things where most of the components are readily available but manufactures have lasered off identification numbers and logos, probably to make my job more difficult because there are others trying to do the same thing to undermine their profits. The ONT falls well into the industrial category. Despite being attached to everyone's house its really not a consumer device; we don't interact with them much, they're directly in contact with your ISP's enterprise infrastructure and you don't really get to shop around for the model you like.
I broke the ONT down into three major systems.
- Power supply and backup
- Usually inside residence?
- Main board
- Networking, cable tv & telephone
- Enclosed in weatherproof box.
- Fiber transceiver
- Converts optical signal to RF for main board to process
- Enclosed in weatherproof box.
Chips & Modules
Fairly standard 12V sealed lead acid battery, 7.2Ah. Charge controller seems regular too. 7-8 color coded wires connect the charge controller to the main board, I assume this is for different voltages, health monitoring and control.
This module is made by emcore and appears to be model Y183-113-001A although the pcb inside is labeled G9823. I can't find any information about it.
The module turns the incoming fiber optic signal into an outgoing RF signal and an incoming RF signal into an outgoing optic signal. It probably uses wavelength division multiplexing and you can clearly see three optic devices attached into some sort of beamsplitter that directs the proper wavelength into the proper silicon. There's probably two photodiodes and one infrared laser diode given that you get so much more downstream bandwidth than upstream.
The whole thing was mounted in a pretty heavy metal case and a couple of the chips inside were in thermal contact with the metal. I assume these were receiver amplifiers or the laser driver for the transmitter.
The only real mystery is the 0.1" header on one side of the module that fits into a socket on the main board. It carries power but I'm not sure what else.
- LT? 901 1665l (voltage regulator?)
- SI Labs F311 BCN01D 0903+ (MCU)
- 4003 EUA (Maxim RF detector?)
- 290 4 (Op-amp?)
- 3658E TG352 INDL (Transimpedance preamp?)
- N1 903G 501S
The main board connects to the fiber transceiver with a small coax cable and a pin header. It regulates all the power and somehow provides us with an outgoing coax connection for cable tv and internet, an rj-45 ethernet jack and POTS telephone connections (including external telephone test points). There is a label on the PCB that reads "533462-005-00 REV B".
There's also like 10 status LEDs. There is a four pin header in the middle of the board for an unknown purpose, a similarly mysterious unpopulated 14 pin header, an unpopulated 2 pin header and an unpopulated spot for what's probably 10 pin JTAG.
The front side of the board is dominated by one large broadcom gigabit ethernet transceiver chip, a BCM5481 in the bottom right corner. There's also a TI431 voltage reference connected to a 2903 comparator and a few hex inverters. This side also has all the connection hardware for POTS, ethernet, telephone test points and coax.
The back side has the majority of the chips, the largest being a broadlight BL2338R ONT SoC in BGA package. The only information I can find about it is that its a GPON (gigabit passive optical network) processor. This chip does most of the computation in the ONT; running high speed network interfaces with its dual-core "runner" network processor and VOIP that might provide the ONT with POTS (this is disputed because there's also a dedicated VOIP processor). According to the spec sheet it only takes 900mA.
Complementing the processor is a 128mb flash memory chip from Spansion and a ram chip of unknown size labeled "9cb41 d9frf". Other interesting small chips around the processor include a couple SC4215 regulators and two PI1622BE tristate 12-24 bit bus exchangers.
Also in the corner is an entropic en2211-b1, which I could find no information on. I assume its similar enough to the entropic en2210 which is a coaxial network controller. This must be what's responsible for stuffing data like cable internet into the coax that feeds into the house.
Just above this here's a large section on the board that appears to be designed to have a shield soldered in place (there wasn't one). This probably generates and controls carrier signals for the coax lines. There's another entropic chip here, looks like an en1010, something to do with coax control. In the same region is a small silver insulated component that I believe is an L466 inductor.
Nearby but outside of the footprint of the unpopulated shield is a shielded module from Macom marked MAFL-008195-CD0AC0. Its listed as a surface mount diplex filter. If you follow the traces on the board, the coax connection from the fiber transceiver is going into the low pass filter port and the common port is attached to the outgoing coax to the house.
Finally there are a couple smaller chips scattered around, a couple of infineon dc/dc converters and a few more voltage references.
The bottom right corner of the board has the ethernet magnetics, HX5008NL.
We were quite keen on learning what is was doing, so we attached it to a spectrum analyzer. Civilian GPS operates at 1575.42 MHz which is near the edge of this particular spectrum analyzer's measurement range, but we managed to produce pretty clean data anyways. This graph is centered on 1570MHz and spans about 40 MHz, clearly showing the jammer's signal from 1560-1580 MHz. The high peak on the upper end of the scale was some sort of transient effect which died down to a normal level after several tens of seconds. Although the graph looks as if it shows several peaks over a 20 MHz range, this is actually an illusion caused by the spectrum analyzer. In reality, the signal is a single peak, rapidly sweeping back and forth between the upper and lower range.
Cheap electronics being what they are, the SMA antenna connector snapped right off (much to the relief of the FCC). The underside of the pads were actually still covered in solder paste that apparently had never been melted during relow. After that we decided to sacrifice it to some destructive testing. We pried open the case and found a double sided PCB containing a voltage regulator, 555 timer, 1.59 GHz VCO and a mess of filtering and support circuitry.
I started by desoldering each SMD component individually using soldering tweezers and measuring each on an LCR meter. Once the board was empty and cleaned I stared really hard at it and used a combination of psychic powers and photoshop to determine how the pads were connected to one another.
Afterward I combined the connections and parts list and drew out the schematics in eagle. I recently found an eagle-to-LTspice export plugin, so it was pretty simple to run an analysis. Sure enough, the 555 timer was feeding a 1 MHz sawtooth wave into the control pin of the VCO to achieve the frequency sweep.
Here's a picture of the circuit and a link to the eagle schematic.
Unfortunately, component L1 was of such a small inductance that our RCL meter was unable to measure it accurately. In addition, I wasn't able to verify what exactly component Q2 was. The small four pinned device had two oblique ground connections, and the remaining pair acted as a diode with a forward drop of about 1 volt. Although this would have been a good place to amplify the output signal with a transistor, this device was clearly unpowered. For now, I'm assuming that it was either a high speed diode or some type of transient voltage suppressant to protect the oscillator circuitry from any radio interference (ha!) that the transmitting antenna might pick up.
What would happen to a banana if all the radioactive potassium it contained were to decay simultaneously?
Mass of average banana: 118 grams
Potassium in average banana: 422 milligrams
- 0.0117% of which is radioactive potassium-40: 49.374 micrograms
Potassium-40 has an atomic mass of 6.64*10-23 grams: 7.43584337 * 1017 atoms of potassium-40
Each atom of potassium-40 can decay into either:
- Argon-40 10.72% of the time, releasing 1.5 mega electron volts
- Calcium-40 89.28% of the time, releasing 1.311 mega electron volts
So, 7.97122409 * 1016 atoms will decay into argon-40, releasing a total of 1.19568361 * 1017 mega electron volts (19156.96 joules)
And 6.63872096 * 1017 atoms will decay into calcium-40, releasing a total of 8.70336318 * 1017 mega electron volts (139443.24 joules)
Totaling to 158.6 kilo joules
We will assume a banana is mostly water (actually 74%, close enough)
Specific heat of water: 4.186 joules per gram
Room temperature is 25 celsius
The specific heat calculation tells us how much an object will heat up when exposed to energy: T = Q/(c * M)
158.6 kilo joules / (4.186 joules per gram * 118 grams) + 25 celsius = 346 celsius
If all the potassium-40 in a single banana were to decay simultaneously, it would reach over 300 degrees celsius and explode with the force of 38 grams of TNT.
@shot_dragon pointed out that I had forgotten to take the heat of vaporization into consideration.
Heat of vaporization of water: 2.257 kilo joules per gram
Mass of vaporized banana: 70.27 grams
This is unfortunately not enough energy to vaporize the entire banana, only 59% percent or so, which would still lead to a sticky awful (burning) mess.
Note: in light of shellshock and other bash vulns I have taken this project off my site. I cannot recommend anyone use it for anything.
You can see my example working installation here: https://deaddrop.goopypanther.org/
The following text is from the readme file on this project's github page.
This webapp allows anonymous users to send messages to your inbox, which arrive signed and encrypted using PGP to ensure message integrity and privacy. Only SSL connections are permitted, which ensures encrypted communication between client and server. What SSL doesn't do is give you any idea of who the server is, be it legitimate or an attacker posing as the server. The internet tires to do this identity verification using CA certs but its a mess and full of vulnerabilities. Ultimately it is no better than self-signing, as CA certs only provide the illusion of identify verification.
The method we must use is called TOFU (Trust On First Use), you may be familiar with this if you use SSH. The client accepts the self-signed certificate and warns you if it unexpectedly changes. There are some firefox extensions such as Certificate Patrol that make this process easier for the end user. The only way to verify the identity of the server is by comparing the key fingerprint on a trusted channel of communication, such as in person or using a shared secret key. For numerous reasons this is beyond the scope of this project.
When a message is typed into the secure text box and submitted, it is securely transmitted to the server, encrypted using the recipient's public key, signed using the server's private key and delivered to a preprogrammed email account. More security conscious users may opt to have this email account be local to the server itself, but it can be delivered to any email account provided the server is capable of sending it.
A word on PGP: Like SSL, PGP is good at encrypting things, but poor at verifying identity. There is a system in place called the web-of-trust where users can verify each other's public key in person and build a network of key-identity connections. Other users can trust key-identity pairings based on how trusted the pairings are by others. The flaw in this system is that it publicly exposes networks of trust between individuals, which at best is detrimental to privacy and at worst is outright dangerous to political activists and dissidents. Again, the method we must use is TOFU. Accept the public key displayed on the site, verify it with a remote key or offline backups and be highly suspicious if it unexpectedly changes.
Because the end user may not yet trust the server's self-signed SSL certificate, they may wish to encrypt and sign their message with the displayed public key before pasting it into the secure message box. This will result in the message being encrypted twice, which is annoying but not much of a problem.
Help, my desk's been taken over by ROV parts. I've got a pcb made up and parts waiting to assemble. My current problem is that the waterproof pumps I bought only run in one direction regardless of polarity. I'll either run the ROV with much limited (although still functional) mobility or chop off the pump section and attach a propeller to the motor shaft.
Most of the core information is available in my github's readme file:
The ROV will be connected to the surface by cat5 ethernet cable, carrying data and PoE at 12-48 volts depending on what power supply I find.
The underwater component will contain a motherboard, power converter and ip camera.
The motherboard contains a passive ethernet hub, connections to the power converter, microcontroller and motor drivers. The system can be programmed by usb connection.
When the motorboard's ip address is visited in a web browser, it responds with a simple html page showing instructions and a live updating camera feed. Pressing the WASD, QE and up/down arrow keys will send GET requests to the onboard webserver that will control the motor drivers. There is also a checkbox that will control an led array for increased lighting. ROV Design
The ROV will have four motors, one each for movement in the X, Y and Z axises and one for rotation of the robot.
All electronics will be encased in a waterproofed pvc pipe that will form the body of the ROV with a window endcap on one side and 5 waterproofed electrical connections on the other. Bits of foam will be used to achieve neutral density.
Motors will be standard brushed dc, placed inside pill bottles filled with paraffin and marine jelly for waterproofing. Propellers will be whatever I can get my hands on.
Code for the embedded server is based off examples from jcw's ethercard project.
I've been a bit busy lately, working on an underwater remotely operated vehicle as part of my university's entrance into the MATE rover competition. The goal of the particular competition this year was to install mock-up research equipment at the bottom of a 17 foot deep pool.
My own contribution focused on the electrical systems, which I designed as a single module to fit inside a waterproof enclosure welded together by one of my classmates.
The propulsion system was made from six waterproof bilge pump motors fitted with propellers; two for depth control and four arranged to give vectored thrust for increased mobility. We also had control over several waterproofed servo motors to operate a robotic claw which we never ended up actually using during the event. Electrical connections through the drybox were made with specialized waterproof marine connectors we got at great discount from SeaCon. The larger one carries all motor connections as well as power to our camera, and the smaller connects to our tether, carrying command data and 48 volt electrical power.
Our internal computer was made from a slightly modified Stellaris Launchpad (several 0-ohm resistors were removed to reroute output ports) connected to a daughterboard with a power regulator, breakout headers for servo and motor control (with current protection) and a TTL to RS232 converter to communicate through a 50 foot long tether back to a laptop on the surface.
Controller boards sat between the microcontroller and the motors, which I designed based around an L6203 H-bridge chip. A small amount of logic circuitry allowed us direct control over motor polarity and duty cycle. Each module was removable and replaceable in the event of failure.
Our microcontroller acted as a gateway between these motor drivers and the surface computer, which did all the heavy calculation for our vectored thrust system. The actual drive interface was an X-box controller communicating with a C# application.
The other board inside the drybox is a switching regulator, bringing the 48 volt power supply from our tether down to 12 volts that ran all the internal systems. Finally a waterproof camera was mounted to the side of the main body with a coaxial cable running up the side of the tether.
Most of the construction of the ROV took place in the week before the competition with about seven of us working 14-hour days amongst our classes.
Unfortunately we did not pass from regional to the international level competition due to buoyancy control issues. The foam you can see attached to the wings in the first image worked well in our local pool (6 feet), but below 9 feet the pressure crushed it. We replaced this with used gatorade bottles while at the competition, which in turn crushed at 17 feet. We eventually were able to use bits of a cut apart fishing float designed to work at depths of up to several hundred feet, but without time to properly calibrate float placement we weren't able to balance the ROV in the water, or successfully reach neutral buoyancy. Our underpowered thrusters were unable to cope with either our positive or negative buoyancy and ultimately we were only able to scoot around at the bottom.
The two other teams in our bracket at the regional competition did not fair much better; the other university present was unable to complete their ROV in time and the local 4-H club (which qualified for the international level) only completed half of the mission objectives (despite operating with a budget 16x larger than ours). If other regional competitions end up having a similar level of success, I think we can expect a relaxation of mission objectives next year.
Our plan for next year's competition is to lighten our frame and replace our motors with a more powerful variety. We'll also be able to do extensive buoyancy testing in both our university's pool and our local lake.
Personally, I am interested in independently constructing a smaller ROV as part of my senior electrical engineering project before graduation.
A few changes had to be made to my board since I last posted, I had forgotten an important capacitor on the reset line. TTL serial programming on AVR chips requires a capacitor between the DTR line and the reset pin on the microcontroller in order to properly form a reset pulse during programming.
I also discovered that I lined up my SPI header backwards; all the pins are in the right order, but the PCB currently has to be turned backwards to fit it in-line with the LED strip. All these changes have been made and commited to the git repository.
Also just as an afterthought I connected the unused CTS line to an I/O pin. In the future someone may want to interface this board with another project, and this way the FTDI header can be used as 3 I/O lines, two of which are connected to the UART system.
Programming of the bootloader was done with a USBtinyISP by inserting the programming pins into the SPI header and the reset line on the FTDI header. The MISO line was connected to the exposed pogo-pin pad on the board and held there during programming by hand. The fuses I selected can be read from the table on the right. Once the bootloader hand been flashed the FTDI header could be used to program the board in the standard arduino environment (the board was flashed and programmed as a Diecimila/Duemilanove w/ 168).
The program I uploaded as a test was a simple rainbow pattern taken from adafruit's demo code. Due to my omission of the DTR capacitor I had to add one between the FTDI header and the actual FTDI cable I was using. New versions of the board will have this included.
Below is a video of the system working with the test program. Partway through I bump the ground line by accident and it briefly disconnects. The LED strip dims but does not go out during this period. My explanation for this is that current is being returned through the data and clock lines and smoothed by the capacitors built into the strip. Its nice to know that the microcontroller can actually sink enough current to keep the strip running without destroying itself, but I certainly wouldn't suggest trying to operate it this way.
|Images from Adafruit.|
After seeing this youtube video of a project called Sound Puddle, I was interested in creating a similar lighting system.
Around the same time Hackerbot Labs purchased a bulk order of addressable RGB LED strip, which seems to be the same model as this one carried by Adafruit. These strips use something like a LPD8806 chip to drive PWM to two LEDs at a time. The strip is marked with white lines every couple inches, where it can be cut to size using a pair of scissors.
Controlling these strips is kind of quirky. LPD8806 chips are actually FILO memory devices, each LED has an associated 3 bytes of memory but the MSB is reserved for chip reset, each channel has 7-bit PWM and data is latched asynchronously. You can get an idea of what's going on if you read the comments at the top of the arduino library file. Due to the chip's FILO nature, all the data to be sent onto the string must be held in memory and can't be generated on the fly and pushed down the line.
The board I designed (available on github) has an Atmega168 with a small microphone and a breakout to the SPI lines. It comes to just under 1.5x4cm which is the same width as the led strip. I'm planning on eventually wrapping the entire thing in heatshrink (the LED strip itself is waterproofed in plastic) and installing it in my shower. Alternatively, the board could be wired up to multiple strips and used in the same way as in the Sound Puddle demo. I'll post some pictures and video of it working once I program it.
Continued from my last post, the serial interface for the antenna rotator is now up on github.
The RX line on the serial header passes through a simple inverting level-shifter using an NPN transistor and a handful of resistors. This line also has a TVS diode tied to ground to protect it from electrostatic discharge or whatever might befall it during use.
The heart of the interface is an Attiny13 microcontroller which handles receiving and transmitting commands. The microcontroller's tiny and cheap and doesn't actually have a hardware UART interface, but its possible to use the USI system (Atmel's name for SPI) for half-duplex UART communication. According to Atmel's appnote on the subject the USI system should first be inactive and a pin interrupt should be used to detect the start bit condition. The interrupt service routine should then enable the USI system and switch its clocksource from the normal slave-clk pin to an internal timer calibrated to run at the same speed as the as the serial data being sent from the computer. Once all 8 bits and the stop condition have been received the USI system switches back off.
From there its just a simple process of matching up the received ASCII character to a table of commands. One pin on the microcontroller is connected to the control box's IR RX line (the actual IR receiver must be removed to prevent shorting) and data is sent across to the microcontroller inside the control box.
It should be noted that IR transmissions are usually sent on a modulated carrier (frequently 28kHz) and the overall waveform looks like a square wave made up of smaller square waves. The IR receiver is tuned to this specific carrier frequency, which prevents natural infrared radiation from interfering with the control signals. The signal that emerges from the IR receiver is stripped of this carrier frequency and looks like a normal square wave containing the binary data being sent to the receiver (usually a few address bits and a few data bits). By bypassing the IR receiver, my microcontroller will be able to send data without having to generate and modulate a carrier frequency.
The actual code that I'll be flashing to the Attiny hasn't been fully written yet. Until I know exactly what data is being transmitted by the remote control it won't make sense to try designing the program. In my next instalment I'll be probing the IR transmissions coming from the remote and coding the firmware to send commands to the control box.
I'm doing work with one of my professors on an automated antenna test platform. We imagine our setup will work as such:
- WiFi router with antenna will be mounted to a general purpose antenna rotator.
- Computer with wifi card will run labview program/etc, map signal strength while rotating antenna.
Unfortunately the antenna rotator we got our hands on has a design out of the 1940's, the rotor base with antenna attachment and the control box have identical motors inside them. Moving the dial on the control box causes both motors to run until a relay is tripped in the control box. The assumption is that identical models of motors will run at the same speed, so dial position on the control box will accurately reflect the positioning of the rotor base. This is of course not how it works in practice, the error between the two builds up quickly and the control box has a feature to resync them (by rotating full left, followed by full right, not a smart device, just mechanical relays).
It turns out that all antenna rotators work like this, in order to remain backwards compatible. Even the newer control box we got our hands on (a Channel Master 9537A Antenna Rotor with an IR remote) was still just an open-loop DC motor driver. It'll have to do.
My current plan is to replace the control box's IR interface with a serial one. The first step is to reverse-engineer the remote control's protocol. This of course started with a google search to see if anyone had already done it. Success! I think. Here's what I found courtesy of Daniel Tonks. They have some sort of fancy universal remote that learned the IR codes of the device and the settings were uploaded to the internet. Here's what I extracted using the software Philips provided:
Each command was prefixed with an identical header: 900A 006D 0000 0001 AC53
Something about this just doesn't sit right with me; its partially that I don't know exactly what these numbers represent (I assume binary data being transmitted) and its also that I've never heard of any IR protocol that would use anywhere near 12 bytes of data per command. I'll have to attach the remote's IR LED to a logic probe and check this for sanity.
In the meantime I'll have to work on the interface circuitry, as it will be the same regardless of what the commands will look like. I'm planning on building a tiny board with a serial header and a microcontroller. I'll remove the IR receiver on the controller and replace it with a signal coming from my board. As long as I sent the right code at the right speed it should perfectly emulate an IR signal.
This blog is powered by ikiwiki.