Rick's b.log - entry 2009/03/03

Welcome to Spring, sort of...

Saturday brought an array of wildlife. The wall lizards enjoyed the sun, and had to readjust to the cat (who has something of a liking for fresh lizard).
A question - can anybody help? Lizards hibernate, right? if we have a nice day and the lizards come out, then it turns cold, do they re-hibernate?
We also saw some bees looking around holes in the stonework, the odd butterfly... no swallows yet, but enough insects to make you think winter may well be done with for this year. The catkins are out on the hazelnut, there is a daffodil in flower (only one, the rest are coming), and both the almond and the oak seem to be budding. It's about the right time for the almond, rather early for the oak.

PVR capabilities

[Scooby Doo (first), shown on ITV1 2009/02/21]

I then copied these to the USB memory and fed them to the PVR, in turn, to see what worked and what did not:

The results of the Rick jury are:

With the exception of the final three MPEG files (which were .MPG), all of the files were in an .AVI wrapper. It is possible (but rather improbable) that the WMV might have played if in a .WMV wrapper - I did not bother to try as various items of software recognised it as an .AVI...

The surprise here, perhaps, is that 3ivx does not work? It may be my settings (though unlikely). I chose the defaults in most cases, though I did set 16:9 aspect for 3ivx and XviD (couldn't find it in the DivX codec!). Needless to say the PVR ignored it. ☺
I wonder how Microsoft's MPEG4 differs from more regular implementations?

I am quite surprised by the range of audio options. Just a shame there is so little control over the format used for recording.

PVR - a delve inside

First, we shall look at the 'topside'...
The picture to the right shows the PVR opened up, like a clamshell, with the right sides touching and the left opened.
You can see that the main board is inserted with the components facing down. We'll look at that in a moment.

The construction appears to suggest that it was intended to have the indicators on the main board, and a little 'power' LED right beside the power jack.
Instead, the control buttons are on a separate board, as anticipated; while the indicators are wires soldered to the correct positions on the main board. These wires do lead to a molex plug so the two boards can be separated if necessary. The always-on blue LED might be a nice touch in the British white i-Recorder, however it is barely visible with the Pearl black design. Looking through the lenses of the indicators that are not active, you can see a faint blue glow.

Three other things of interest - to the back right of the main board (by the power connector) is a push-switch. It is inaccessible, there's no hole in the casing or anything like that. As you can imagine, I am loathe to press it as the only way to do so is to take the device apart. It may be that another version mounts the main board the other way up (with indicators on the main board) and there's a little hole to activate a 'reset' button? It may be. But on the other hand, maybe it is an 'emergency reflash' button and when pressed the system will try to reflash itself using something supllied on USB memory key, or the like? There are no indications (like "RSTSW" etc) on the board itself.
The second item of interest - front right of the picture. That's an awful lot of connections. We probably aren't talking an SD card here. Looking at the number of connections and the size, it could pass as a tiny IDE interface. In other words, a CF card?
The final thing to consider are the empty pins in the board to the right of the unknown switch. The function of these is open to wild speculation - from a potential socket for additional controls all the way to a plug-in ethernet board.

If you think I'm being way too enthusiastic suggesting things like CF cards and ethernet; I read somewhere (but have lost the PostIt I wrote the URL on!) that the TMS320DM320 is the video processor used inside the Neuros OSD. I'm not entirely certain that I trust this, as the capabilities of the OSD leave this PVR standing - surely they can't use the same chip!? [actually... they do! the Neuros wipes the floor with this PVR, and it is pretty much the same hardware!]

Now a picture of the underside of the inside, the component side of the main board...

[click here for a ridiculously oversized version - 1474×1129, 523Kb]

Tidy, organised, clearly marked, and numerous test points provided. If you have the documentation and a reasonable compliment of test equipment (multimeter, 'scope, etc) then finding your way around this little contraption probably won't present too many difficulties. It is all surface-mount construction, with attention paid to minimising electrical 'noise' (EMC). To this respect, it is rather a shame that the plastic casing isn't metal-sprayed. Recording (to a decent USB device) is fairly quiet, but playback is hell! Tests conducted with a damp stone wall approximately a metre thick showed that the intolerable interference to mom's radio when playing back passed through the wall and over ten metres beyond. This was rather more than a WiFi installation was capable of achieving! [the WiFi could barely make it from one side of the wall to the other]
While we are here, note that there is nothing adjustable. No POTs or VCAPs or anything of that nature. It's the digital age now! ☺

If you don't know what I mean by that, go buy yourself a cheap Sony ßetamax VCR at a boot sale. Look inside. Imagine being the poor soul having to set that up!
[oh, and if you then decide you no longer want it, post it to me please! I really could do with a replacement ßetamax deck!]

The layout can be summarised as:

• Upper left, battery-backup. Note the tiny crystal by the eight-legged IC (NVRAM?) for keeping the clock up to date when the power is off.
  Incidentally, that unknown button is more or less on the other side of this; perhaps it is an NVRAM clear? Who knows...
• Centre-right, the heart. The processor/DSP that makes it all tick.
• Centre-right-bottom. The FlashROM containing the device's firmware.
• Right. The RAM, an essential part of the system for buffering video, remembering status (what files are on the USB device, blah blah).
• The rest? Centre-top and the IC top-right? Currently unknown. The IC top-right appears to be something to do with video I/O...? [fail! the IC top right is the audio coder/decoder; while video is handled by the itty-bitty square chip between the TMS320 and the battery]

For reference, the connections across the top (as seen in the picture) are:

The 'processor'
The processor is a TMS320DM320. I have found little information on it as it is a discontinued product, dating from around 2004. At its heart are two parts - the first is a video DSP which appears specifically optimised for reading data from a CCD imager, plus a complete LCD controller. This multipurpose device is, obviously, targetted at digital cameras.

The thing with DSPs is that they are really good at specific repetitive tasks. A very common example of a DSP is any USB 'stick' MP3 player. The DSP part is optimised to play MP3 audio at lowish clock rates from a single AAA cell - consider how much processing power is required to play MP3s on a computer? A 40MHz ARM (RISC) can't quite do it, though there are suggestions that a 56MHz ARM7500 can. You'd just about get an 90MHz Pentium (CISC) to play an MP3, but it really requires something faster. All of the above would fail if you hit it with a 320kbps file and all of the above require considerably more resources and power then would be easily achievable in a chicken-nugget-sized device with a single AAA cell to power it. You might get a StrongARM squeezed in there, but a Pentium?!? :-)

So the DSP in the PVR looks after the video and audio compression/decompression. What provides the user interface? The controls? The FAT16/32 knowledge for permitting storage devices to be connected to the USB port? If fact, what synchronises everything? Answer? The processor. As in an actual real processor. Specifically the ARM926EJ-S clocking 160MHz. Bizarrely, the 'J' in the processor core part number is because the processor is capable of executing ARM instructions, Thumb® instructions (a sort of microcosm of ARM), and also some? all? Java bytecode!
The processor core is, specifically, the ARMv5TEJ architecture (in other words, one of the ARM9E family). It offers Thumb® which is a reduced 16 bit version of the ARM instruction set, to permit the ARM to be used in a 16 bit 'world' (i.e. cheaper memory and cheaper board layout; sometimes a 32 bit datapath is overkill). It offers various DSP-specific instructions which aid in interfacing the processor to a DSP (think of how x86-alike processors have MMX extensions to provide enhanced multimedia capabilities). And it offers the Jazelle DBX which is a seemingly undocumented (?) method of executing Java bytecode. This might make some sort of sense in a set top box with downloadable software (games and such), but I'm not sure Java is something we'll be needing on a video recording device!

This same processor core, one of many in the ARM family (and yes, that ARM - as in RISC OS and Acorn once upon a time!) is also found in various mobile phones (Sony Ericsson K and W series, for example), a large variety of Texas Instruments (TMS) OMAP digital image processors (like, perhaps, this? :-)), and is also - apparently - the undocumented core of the ATi graphics chip used in the Wii.

Looking in various references and datasheets for other members of the TMS320DM3x series, it would appear that some of the technical factors are probably limitations in the firmware rather than limitations in the device itself - the main two being that it only outputs in NTSC and that the maximum possible resolution is 720×480 (instead of PAL 720×576).

The USB bus can run at up to 12Mbps, though firmware factors may reduce this slightly 'in the real world'.

The user memory
The SDRAM, of which two are provided, are K4S281632I-UC75s. The memory is laid out as 4 times 2,097,152 16 bit words. Or, in English, it provides 32Mbytes.
The maximum clock rate is 133MHz, and the SDRAM runs on 3.3V.
I do not currently know if the PVR is arranged as 64Mbytes using 16 bit access, or if the two run side by side to provide 32Mbytes worth of 32 bit words.

The Flash memory
The Flash device is a S29GL064N90TFI04. This is a 64Mbit device, laid out 4,194,304 16 bit words, or 8Mbyte in total.
The device offers 90ns access rates, is lead free, TSOP pinout, and looks as if it is 8 bit/16 bit capable and offers the bottom two 'sectors' as protected boot sectors. It runs, nominally, on 3.3V (3.0V-3.6V).
As this is a 16 bit device, I would imagine that it is possible a lot of the software uses Thumb instructions; however there is nothing to stop a 16 bit Thumb bootstrapper copying data from the Flash into 32 bit RAM where it is then executed in full ARM mode. Not saying this happens, it's just a fairly trivial way to economise, plus softloading speeds things up as the RAM is faster to access than the FlashROM.

Everything else...
There are many things as yet not understood...

Does the TMS320x accept video signals directly [no, the tvp5150 accepts video and converts that into a digital bitstream; the TMS320 thinks it is talking to a CCD imager!], or is it split into chroma/lumi? If so, that would imply the device is S-video capable [yes, the tvp5150 video processor accepts either composite sync or s-video, but not in this PVR...]? Whatever passes the video into the chip (if indeed there is buffering and/or sync-split and/or Y/C separation?) is either fairly passive or specifically supports both PAL/NTSC [correct - it auto-syncs to PAL, NTSC, SÉCAM, or the variants like PAL-M; this being translated to the CCD-like bitstream, so with pretty much any input, the TMS320 will see something]. As a strange oddity, I managed to get a good colour recording of an episode of "Pushing Daisies" when the PVR was incorrectly set to NTSC mode - the problem was that the bottom of the frame had been chopped off as NTSC is only 480 lines instead of PAL's 576... While the actual 640×480 resolution is not up to PAL spec, we don't miss big bits of the picture, it is 'rescaled' to fit; however in NTSC mode, a smaller area is scaled to fit so you lose the bottom fifth (?) of the screen. [correct - NTSC has fewer "active lines". The TMS320 has a hardware-assisted resize engine which maps the incoming video into a specific shape and size, on the fly. Thus all sorts of inputs can be mapped to standard sizes like 640×480, however in the case of NTSC the actual useful size of the picture is smaller than its PAL counterpart, so a PAL input when in NTSC mode would result in some apparent cropping]
If likewise on the output path, perhaps this could explain why it is NTSC output? [No, it is probably lame firmware, for the TMS320 can output, itself, either PAL or NTSC. The only difference is, again, the output needs to be jiggled slightly for the different sizes of output picture] Though to be honest I think this is an oversight, like it's target market is America and Europe was rather incidental so it's probably a firmware issue.

The RTC - what/how? Would it be feasible to have it turn itself back on after a power outage, say, for timed recordings? Or, perhaps, to pick up and resume if a recording is (was?) in progress? Would it be possible for it to switch on and begin recording if it was off? The power button is connected to the keyboard matrix and/or the IR receiver, so the system isn't totally dead in standby mode.

Which would require some knowledge of... the firmware. Even with a datasheet, the DSP is going to require a lot of assistance. For example it might be possible to say "this is 20 frames of MP3 audio, play it" but how? Reading from a USB stick? Where's the USB driver? What understands FAT-formatted devices? Or maybe NTFS for those really big plug-in discs? Even with a datasheet, creating all of that from scratch is just going to be a bit of a headache.
It is possible that much of this is standard TI library code, you sort-of bolt together a media player with the pieces (this could explain the simplistic interface? the OEM can make it as simple or as complex as they feel inclined).
The problem here is... well... where's the Texas Instruments development kit for the TMS320DM320? This is, obviously, assuming that the iPod recorder PVR follows some sort of 'standard' design. No good talking to our IIC NVRAM to find it is actually a memory-mapped chip!

Can YOU help?
I am guessing that the device is made in China. It doesn't actually say, however there are two built-in languages, one of which is Chinese...
I am guessing it is intended for the American market. This is due, in part, to the maximum 720×480 (an NTSC frame) plus it outputs NTSC (only). The user guide, on choice of video format, says, basically: if you live in the United States, you should select the NTSC standard. Need I say more? ☺

What I haven't been able to do is track down a source for this device. I doubt any company reselling the device will want to tell me their supplier in case I am trying to undercut them. I might try contacting Texas Instruments as their shipping a load of these to a company in China might be a way to try to determine who put this PVR together. This is, of course, assuming that they are willing to disclose such information and that the manufacturer ordered direct and not via an intermediary (such as would be the case if I placed an order for 1,500 of them from Farnell or the like).
There is no indentification that I have found in the PVR's displays - it just says that which you can see on the information screen (product title, software version). There is nothing obvious on the board or inside the casing. The firmware dump that I managed to obtain from the iRecorder website (may or may not be complete? seemed to download too quickly...) would appear to be scrambled in some manner (perhaps compressed?), hence any embedded messages will not be visible. The manufacturer is completely hidden, unknown. Probably in China. Gee, that narrows it down! ☺ [Unisen make this. Their engineer was going to contact me... I'm sure you know how that story goes. It looks as if the 14 pin space-for-a-socket is JTAG; so if I ever get around to a cheap'n'cheerful JTAG interface, I might see if I can sniff out the firmware and replace it with something else; perhaps a port of RISC OS? Might sound odd, but RISC OS has been ported to the Beagleboard, which is a later series (OMAP) TI ARM-based 'solution'...]

If you can help - if you know of somebody selling these devices, if you know of the manufacturer, if you have a TMS320DM320 datasheet (pref. PDF) and/or development information/software... please contact me!
[All info welcome, but you'll find the datasheet in the entry given at the top of this section]

An extra incentive: If we ignore the PAL issues as I've bleated about it a hundred million times already, then consider this: I am familiar with the ARM. Not a wizard by any means and not up to speed with the Thumb, however an earlier version of the ARM is the heart of my RiscPC, or A5000, or A3000, or A310, or the A7000 board, or the IBX-100 ("Bush box")... get the idea? ☺
I feel that this is potentially an ass-kicking budget digital video recorder. It just suffers from not having quality options on the audio and video recording, and it suffers from being too heavily targetted towards the iPod. For certain that's a big market. Now consider if it could rejig the MPEG-4 video data into an XviD within an AVI wrapper (instead of .MP4 file), didn't split every hour, didn't bury the file in \iPod_Control\Music\f00\. I could record to something to plug-and-play (literally) on my DVD player, my friend's DVD player, my Zen (via SD card)... all these devices support DivX (I use XviD, compatible!) but these things don't like the .MP4 files created using the iPod recorder; hence why I perform the long transcoding process... And maybe other people have figured this out too?
This little device could go from being a mostly-iPod-specific video recorder to being a solid general purpose budget digital video recorder. It is my personal belief that it's just a matter of having capable firmware.
Anyway, given resources, I am willing to have a crack at doing this. Oh, I'd better point out in case it wasn't totally clear - for free. Gratis. After all, I will benefit too! [To be honest, I am more likely, right now, to look to doing something with the Neuros OSD; for it can netboot, it IS a fairly open design, and it has more functionality; however if I ever get anything running, there should be enough similarities to make a port to the iPodRecorder possible]

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.

No comments yet...

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 40615 backwards.
		Your comment