It is the 1729th of March 2020 (aka the 23rd of November 2024)
You are 18.220.112.210,
pleased to meet you!
mailto:blog-at-heyrick-dot-eu
Into the PVR
Power
Most of the ICs run at 3.3V, while some of the video inputs run at 1.8V. The input power will be regulated down to the desired voltages. There are no big heatsinks as the devices used are extremely efficient.
While I have not looked in detail, those not-quite-transistor looking things just below the NVRAM (to the left in the picture above, by the yellow lumps) are pretty good candidates for the power regulation.
Clocking
There are numerous oscillator crystals on the board...
RTC clock
This is an oscillator running at 32.768kHz, like pretty much every clock in every RTC and digital watch on the planet. This frequency is a multiple of two - 215 ticks per second, so a simple binary counter/divider will lead to a precise second-by-second result.
USB clock
The 48MHz oscillator (near the CPU-DSP) is used for the USB interface.
Main system clock
A 27MHz oscillator (near the CPU-DSP) is the main system clock. The CPU-DSP syntheses all the necessary internal clocks from this. It is difficult to extract exact clocking from the datasheet, so it would appear that...
CPU - up to 160MHz (not 320MHz as stated in other sources?)
DSP - up to 100MHz
Memory interface - up to 100MHz.
Imaging extension - up to 180MHz?
Others...
Video decode clock
The video decoder would appear to run from a single 14.31818MHz oscillator, synthesising the necessary clocking for its CPU and DSP internally.
Audio decode/encode clock
The audio encoder/decoder would appear to run from a single 12MHz clock, synthesising the necessary clocking for its CPU and DSP internally.
RTC
PT7C4337 RTC (datasheet, 622Kb)
This is an I²C device that maintains the date and time. Unlike the popular Philips PCF8583, this has no NVRAM provision. From this, I can only surmise that settings and schedule entries are written to FlashROM.
Observation - settings are written only when the device is correctly powered down. If power is lost, all settings and schedules will revert to the last stored values. If power is disconnected before the device has fully shut down (the green LED is no indicator, you must wait until the blank screen on the TV switches to the pass-through of the input signal) there is a chance the settings will be corrupted. The device can cope, but you may have to undo every schedule entry starting and stopping at 255h255m!
The datasheet claims to require the installation of 26Mb of Chinese fonts. This is not necessary.
NiCad battery
Standard NiCad battery, probably around 3.3V. Most likely trickle charged from the main power supply.
Memory
S29GL064N FlashROM (datasheet, 3.3Mb)
This is a 64Mbit (8Mb) FlashROM operating entirely at 3.3V (including programming). Offering a 90ns access time, and with the bottom two 'sectors' protected, the entire external storage capacity is 8 megabytes. It may be, however, that this is accessed as 16 bit words in order to utilise the ARM's Thumb mode.
The FlashROM holds the system firmware. It is also believed that a part of it holds the settings.
The system firmware is upgradable from a file placed upon the attached USB memory, however the firmware available from the manufacturer would appear to be older than that actually present on my PVR!
K4S281632I SDRAM (datasheet, 146Kb)
This memory device offers 2Mbit by 16 bit by 4 banks (!) storage. As there are two such devices, each offering 128Mbit, this would imply that the RAM capacity is 32Mb.
It is not currently known if this memory is accessed in tandem as 32 bit words, or if it is banked as two devices operating with 16 bit halfwords. The memory controller can support both, as can the ARM.
Audio and video
TVP5150AM1 (datasheet, 375Kb)
This device is capable of accepting NTSC, PAL, and SÉCAM at either 50Hz or 60Hz (in other words, all global variations of traditional analogue broadcasting), though the firmware only permits NTSC or PAL. That said, the device is still fully capable of extracting a stable colour signal from a PAL input when the PVR is in NTSC mode - the only difference is the bottom part of the picture is chopped off (NTSC is 480 active lines, as opposed to PAL's 576). It can accept either two composite or one S-video input, though the PVR is fixed to a single composite input. This is less of a problem than it might otherwise appear as clever stuff inside the device attempts to minimise the effects of high frequency luminance interfering with the chroma - a traditional problem with PAL leading to the "electric schoolgirl" effect where a gingham pattern uniform dress can seem to fluouresce as the detail in the picture interferes with the colour information, as demonstrated by the picture on the right (resized from original, click image to go to source).
In addition to this, there is more cleverness aimed at getting a good lock on to an irregular signal. I have not tried recording from video using my PVR yet, but I can say that doing such a thing using the TV tuner (PCI BT848-based miró capture card) was more or less a disaster on anything recorded "off air" from a UHF input. The noisier the signal, the worse the result - which meant my capture card failed miserably on anything recorded from Channel 4 way-back-when. I wonder how the PVR would fare?
The eventual output is ITU-R BT.656, 8-Bit 4:2:2 (oversampled for better results) which is supplied to the CPU-DSP for encoding.
Full brightness, colour, contrast, sharpness, and hue adjustment is available, none of which is utilised by the firmware. Shame, I think a bit more sharpness would be nice. Control of the device is effected through the I²C bus.
AIC23 Audio Codec (closest match datasheet, 490Kb)
This device appears to handle the audio paths, both digitising input audio and creating analogue output from digital data. It supports data-transfer word lengths of 16, 20, 24, and 32 bits, with sample rates from 8kHz to 96kHz, though I would imagine we're using a standard 44.1kHz sampling rate in the PVR.
Looking at the data sheet, it would seem as if calling it a codec, whilst correct ((en)coder/decoder) is not quite the same as its computer counterpart. You can have an "MP3 codec" or an "AAC codec" on your computer, but this device is more an ADC/DAC which accepts or outputs digital serial data from/to analogue inputs/outputs depending on which way we're working.
Observations - the PVR is far better at recording video than it is at playing it. On playback, stuttering is fairly frequent at 720×480, slightly less so at 640×480. I originally wondered if this was a buffering issue, but looking in more detail it is not immediately clear how the video is played back. There is video output capability in the CPU-DSP, however the problem is that whenever the PVR is in use, you are seeing the video output from the device. The menu displays, the record mode 'preview' and while actually recording... Perhaps it is easier and faster to take the data from the 5150 and paste in any overlays and whack it to the video output than to decode and generate one from encoded data?
Another thing that I have not sussed yet is how the scaling is performed. There is very little between 720 across (actually 704 in PAL) and 640 across. Are we simply discarding every 10th pixel, or something? Likewise, how are we munging 576 lines (PAL) into the 480 lines supported by the PVR? That's a loss of 96 lines. Surely we aren't chucking every sixth line? The 5150 has a 'cut-out' facility, but does not appear to support scaling. Certainly, the scaling method used is fairly simplistic as can be seen at the lower resolutions where no anti-aliasing is being performed.
Finally, is it possible for the AIC23 to work in both directions at the same time? Or is watch-while-recording audio simply looped through?
CPU-DSP
TMS320DM320 (datasheets part 1, 3.25Mb; part 2, 1.05Mb; part 3, 1.51Mb)
Publically known information is that this device contains a C5409 16 bit fixed point DSP, plus an ARM926EJ-S processor. It runs (internally) at 160MHz ... some sources say the CPU is clocked at 320MHz, however the datasheet (part1p38) says otherwise.
That said, the datasheet does not seem certain on the SDRAM frequency - in the overview it claims to support up to 108MHz SDRAM (part1p13, part1p23) while the SDRAM controller information claims to support up to 100MHz (part1p394). Which is it?
In any case, here's the complete feature list of what the TMS320DM320 offers:
180MHz (or 160MHz elsewhere in the datasheet!) ARM926EJ-S 32bit RISC CPU with 16Kb instruction cache, 8Kb data cache, MMU, Java accelerator, Thumb mode...
Texas Instruments C54X class DSP core clocked at 100MHz, with 128Kb on-chip program/data memory.
Support for up to 256Mb of SDRAM accessed either as 16bit or 32bit interface, clocking at up to 100MHz or 108MHz (depending on which bit of the datasheet you read!).
Dedicated SDRAM DMA channels, 3 plus image buffer.
Support for up to 16Mb of FlashROM.
On-chip 8Kb (Flash?)ROM and 16Kb memory internal to the ARM. I assume this is separate and distinct to the two caches.
24Kb image processing buffers
Image processing engine running at 180MHz to process images with MACs. This gobbledegook means that there's a specialist DSP in addition to the regular DSP which can assist with specific image-related tasks like DCT tables, motion estimation...
DCT module to perform (I)DCT transforms. JPEG/MPEG uses DCT to compress image data, and IDCT to decompress it. It is horribly mathy and more or less incomprehensible to normal people, so just know that this is a fairly integral part to video (de)compression.
Likewise quantisation is important, and a variable-lenth coding/decoding coprocessor is available and able to work fairly automymously from the DSP.
Intelligent sequencer for getting the ARM, DSP, and all these specific co-processors all working in harmony.
Preview engine to support real-time preview (along with digital zoom, though not necessary in a PVR).
Hardware-based module for auto-exposure, white-balance, and focus. Not necessary in a PVR, but you can see some digital camera support going on here, can't you?
Powerful and versatile on-screen display (OSD) system with support for colour LCD plus video output.
Interfacing for CF, SM, MMC, SD and Memory Stick cards.
USB 2 support, either as a slave device (usual for digital cameras) or a host device (as used by the PVR). Full speed dual role OTG controller, with full USB device and limited USB host support. DMA available.
One 27MHz oscillator to generate all the internal clocks, plus a specific 48MHz oscillator for USB timing.
Four internal programmable timers, plus an optional watchdog timer to restart upon failure.
Two UARTs for serial interfacing, with a pretty impressive 32 byte FIFO in both directions.
10 bit DAC for NTSC/PAL composite video output.
McBSP serial audio interface (connects to the AIC23B).
SPI and I²C serial interfaces, with I⊃2 "bus master" (host) capability.
41 general purpose I/O pins (actually I believe some are specific to interfaces such as I²C, but there's otherwise plenty for keypads and LEDs...).
ROM boot loader which can load in firmware from an attached Flash.
CCD interface to connect to CCD imagers up to 4096×4096 (16 megapixel).
Confused? Well, here's a rundown for you:
FOR RECORD: The incoming video signal is sliced into digital data by the 5150. It just so happens that the output format is exactly one version that is supported by the CCD interface. The ARM-DSP thinks it is connected to a small CCD imager, when in reality it's a composite video signal.
The preview engine is used to resize the image data. This implies that 720×576 could be possible. Whether we're stuck with the naff-looking lower resolutions, or whether the device can better anti-alias if configured more appropriately remains to be seen.
The DSP and all those coprocessors work in tandem with the CPU and memory to convert the image data now in SDRAM to a sequence of MPEG4 H.263 frames.
These are, eventually, written out to a FAT filesystem on a USB memory device. Since files are arbitrarily limited to being an hour long, there's no requirement for the device to be FAT32, as the files will be less than 2Gb (in fact, I've yet to have a file over 800K; it seems to run around 450-650Mb/hour depending on the source material).
The state-of-play (be it menus or preview with overlay) is passed to the video encoder which is capable of generating a composite video signal. Note specifically that 50Hz PAL is an option!
Audio, in whatever direction, is handled by the AIC23B which communicates using a specific type of serial communication to the DSP which encodes the audio to AAC.
FOR PLAYBACK: data is read from the USB device. Under CPU control, a variety of MPEG video formats (VideoCD, PVR MPEG4, XviD, DivX...) and related audio formats (AAC, MP3...) are decoded by the DSP and the coprocessors and written to SDRAM. This is then picked up by the OSD controller for overlays, if necessary, and then passed on to the video encoder.
Audio, as before, is decoded by the DSP and passed via serial interface to the AIC23B.
Some observations:
The hardware would appear to be D1 (720×576) capable.
The hardware would appear to be fully PAL/NTSC capable.
I suspect this was intended for the American market and the fact it works with PAL is more an afterthought than a design criteria. Certainly, it would appear that all PAL mode does is instruct the PVR to 'see' more of the input image. Otherwise, the PVR is fixed to NTSC-like resolutions, NTSC-like frame rate, and outputting NTSC. See a pattern here?
CF and/or SD support is provided by the hardware. I don't know about SD cards, but the circuit board looks like there's a place waiting for a CF connector to be included, though this does not appear to be referenced at all in the firmware. Shame, it would be nifty to have the option to record directly on to SD cards.
The odd paths where video is actually stored, plus the hour limit, would appear to cater for specific ideosyncracies of the iPod. It's a shame this can't be disabled so it would be possible to at least record a video in one single file.
Likewise, support is for MP4V with AAC audio. This is similar, but incompatible with XviD.
It is ironic that the Neuros OSD makes a big point of playing "The Neuros OSD records in the standard and open MP4 format compatible with a wide range of devices. Videos recorded with the Neuros OSD can not only be played a TV set using the OSD as a player, but can also be viewed on PC/Laptops and popular PMPs like the iPod/Nano/iPhone, the PSP, smartphones etc..." and this is perhaps the same approach taken by Unisen with this PVR... DivX is proprietory, XviD is not. MP3 is proprietory, AAC is not. Where this falls down, however, is in the use of an MP4 wrapper. There are many computer-based devices capable of playing these files. On the other hand, numerous stand-alone DVD players only recognise video files in an AVI wrapper. Could they play this type of video? Perhaps - standard SD MPEG4 video (H.263alike) is broadly similar. Can they understand the file format? In short, no.
It's sad that these (broadly compatible) formats can be played but not recorded.
There is support in the hardware for widescreen. All it needs is some support in the firmware! Given the 'hidden' menu in playback, it would seem this was sort-of thought about, but it would need support at record time to flag the video file as being 16:9.
It would be nice to have an option to control the brighness, contrast, sharpness, etc. The hardware can do it...
For Americans - the hardware supports Closed Captioning.
For Europeans - did you know the 5150 can extract WST teletext? Probably little call for it on a PVR, but wouldn't it be awesome to auto-sync to P888 (configurable, as that's only a British convention) and place anything received in as an MPEG4 subtitle frame?
Not yet sure how the IR controller works. I suspect there's an IC on the other board that reads IR and fakes the appropriate button presses. Apart from left/right and ffwd/rewind, all the functions are duplicated by buttons on the top of the PVR.
For now, as I am using my PVR, this is about as far as I plan to go. Certainly I do not know the specifics of the update file format, nor do I have JTAG (etc) hardware, so geeky tomfoolery (like extracting the firmware for safe keeping and attempting to push a minimal RISC OS kernel onto it) will remain an amusing dream but never a reality.
Of course, if somebody else with more experience and better hardware wants to fiddle... the datasheets are here and you can buy one here (France) for €89,90 or here (Germany) for €39,90. Don't ask about the price difference.
You can apparently get one here for a mere £99.99.
A British site, http://www.i-recorder.co.uk/ was offering it for about the same price, and also on Amazon.co.uk, but this site seems to have never taken off and it looks like it's been more or less dormant since the end of 2008.
I have not seen a US retailer. Ironic, given its affinity with NTSC!
It is perhaps worth noting that the bulk price, if you order a load of them, is 350 yuan which works out to be about 38 euros. Pearl Germany are selling them at cost, Pearl France (probably the same big warehouse!) is making a profit for no good reason, and... need I mention Rip-off Britain? &9786;
Processor-frenzy
So let's get this straight. The video decoder contains a processor of some sort plus a tiny bit of firmware. The audio processor contains a processor plus some firmware. The CPU core contains an ARM processor plus firmware which is distinct from the processing capabilities (and firmware) of the DSP, not to mention the coprocessors for image processing, DCT, VLCD...
Not only does the main CPU-DSP have a DSP, but so do the video and audio ICs.
Whoa.
Reseller...
The i-Recoder website mentions about becoming a reseller, saying:
We are looking for companies, stores and traders to become resellers of the iRecorder. This is a new exciting product that will be a massive seller in 2008.
It is so close to being true. But, there are problems that make it less so.
NTSC. I cannot say this often enough, for those of us without auto-multi-standard TVs will see it all in scrolling monochrome. The vertical hold will steady the picture, but NOTHING will bring colour to an NTSC-incapable set. It would appear that it's a matter of simply altering the video encoder setting!
Dude, where's my file? Okay, so it is an iPod recorder. How about a non-iPod option to make it record to the root folder?
It doesn't play! You can talk about standards all you want, but if people stick their USB device into their DVD recorders and it doesn't even see the file, never mind play it...
The non-iPod option should switch to something akin to XviD in an AVI wrapper.
More control. It is lazy to not include options for brightness, contrast, saturation, sharpness, widescreen... and while you're at it, a recording "quality".
Remote control. Okay, it keeps the price down, but it is a pretty icky remote. For people making a lot of use of their PVR, expect it to last about six months. It can be 'patched', but it would be better if it was less naff in the first place.
Expand your horizons. You might be aiming for iFanbois who thinks the sun shines out of Mr. Jobs' posterior, but really this device is capable of above-videotape quality recording. Not DVD quality, but then the file sizes don't compare - two hours of film on a 9Gb DVD as opposed to two hours from the PVR in around 1Gb... Sell it as that. An inexpensive simple video recorder replacement. It works fairly well at that.
PRICE! A hundred quid is ridiculous. For the price difference of a beer and pack of smokes, you could instead get the Neuros OSD. Wanna compare the feature set? Wanna ask how come one has ethernet and the other doesn't? Don't even go there. Fifty quid (and about fifty euros) is the top this gadget should cost.
Your comments:
Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.
- entry 2010/01/31
