This particular IC came out of a very old VHF band radio, from the early 90’s. The die was encased in a custom ceramic package, like every other IC in the radio, with a custom part number. I managed to identify it from the markings on the silicon.
This was a pretty powerful MCU for it’s time, with 16K of onboard ROM, 512 bytes of both RAM & EEPROM, a 16-bit timer, 8-bit ADC, SPI & a MC68HC11 CPU core.
I recently dug out my other card printer to fit it with a 12v regulator, (it’s 24v at the moment), and figured I’d do a teardown post while I had the thing in bits.
This is a less industrial unit than my Zebra P330i, but unlike the Zebra, it has automatic duplexing, it doesn’t have Ethernet connectivity though.
Unlike domestic printers, which are built down to a price, these machines are very much built up to a spec, and feature some very high quality components.
Here’s the mechanism with the cowling removed. This is the main drive side of the printer, with the main drive stepper at left, ribbon take-up spool motor lower right, and the duplex module stepper motors at far right.
The main drive motor runs the various rollers in the card path through a pair of synchronous belts, shown here.
The stepper itself is a quality ball-bearing Sanyo Denki bipolar motor.
Electrical drive is provided to the stepper with a L6258EX DMOS universal motor driver. This chip can also drive DC motors as well as steppers.
Here is the encoder geared onto the ribbon supply spool. This is used to monitor the speed the ribbon is moving relative to the card.
Here’s a top view through the printer, the blue roller on the left cleans the card as it’s pulled from the feeder, the gold coloured spool to it’s right is the ribbon supply reel. The cooling fan on the right serves to stop the print head overheating during heavy use.
The spool take-up reel is powered by another very high quality motor, a Buhler DC gearmotor. These printers are very heavily over engineered!
This motor drives the spool through an O-Ring belt, before the gear above. This allows the drive to slip in the event the ribbon jams, preventing it from breaking.
The pair of steppers that operate the duplexing unit are driven by a separate board, with a pair of L6219DS bipolar stepper driver ICs. There are also a couple of opto-sensors on this board for the output hopper.
All the mechanisms of the printer are controlled from this main PCB, which handles all logic & power supply functions. Sections on the board are unpopulated, these would be for the Ethernet interface, smart card programming & magstripe programming.
The brains of the operation is this ColdFire MCF5208CVM166 32-bit microprocessor. It features 16KB of RAM, 8KB of cache, DMA controller, 3 UARTs, SPI, 10/100M Ethernet and low power management. This is a fairly powerful processor, running at 166MHz.
It’s paired with an external 128Mbit SDRAM from Samsung, and a Spansion 8Mbit boot sector flash, for firmware storage.
Here the USB interface IC is located. It’s a USBN9604 from Texas Instruments, this interfaces with the main CPU via serial.
It’s official. I’m now part of the uRadMonitor network, & assisting in some of the current issues with networking some people (including myself) have been having.
It seems that the uRadMonitor isn’t sending out technically-valid DHCP requests, here is what Wireshark thinks of the DHCP on my production network hardware setup:
As can be seen, the monitor unit is sending a DHCP request of 319 bytes, where a standard length DHCP Request packet should be ~324 bytes, as can be seen on the below screen capture.
This valid one was generated from the same SPI Ethernet module as the monitor, (Microchip ENC28J60) connected to an Arduino. Standard example code from the EtherCard library was used to set up the DHCP. The MAC address of the monitor was also cloned to this setup to rule out the possibility of that being the root cause.
My deductive reasoning in this case points to the firmware on the monitor being at fault, rather than the SPI ethernet hardware, or my network hardware. Radu over at uRadMonitor is looking into the firmware being at fault.
Strangely, most routers don’t seem to have an issue with the monitor, as connecting another router on a separate subnet works fine, and Wireshark doesn’t even complain about an invalid DHCP packet, although it’s exactly the same.
As the firmware for the devices isn’t currently available for me to pick apart & see if I can find the fault, it’s up to Radu to get this fixed at the moment.
Now, for a µTeardown:
Here is the monitor, a small aluminium box, with power & network.
Removing 4 screws in the end plate reveals the PCB, with the Geiger-Mueller tube along the top edge. My personal serial number is also on the PCB.
The ethernet module is on the right, with the DC barrel jack.
Here is the bottom of the PCB, with the control MCU & the tiny high voltage inverter for the Geiger tube.
A Closeup of the main MCU, an ATMega328p
PCB Logo. Very artsy 😉
