Re: Chumby NeTV?

Adding "support" for 1080p60 is technically a matter of adding its mode to the timings file and recompiling.  I forget what the exact numbers are, but if you run "killall matchmoded; matchmoded --debug" and switch the input to 1080p60, it'll print out [roughly] the right numbers.  You can then add those to the timings header file and rebuild, or write a program that simply opens up /dev/fb0 and sets those numbers manually.

The problem is that the FPGA just can't keep up with that resolution.  The link is not stable -- you'll see it show a few frames of video, then the screen will go dark, then show a few more frames.  Worse, there tends to be a lot of smearing and sparkle on the output.  There's no real danger from overclocking, it just doesn't look good at all, assuming it even syncs.

It works without an input.  When it first boots, it's running a version of the FPGA file that only does output, because the bootloader doesn't have the knowhow to negotiate the HDMI link.  If it detects no display connected, or if it detects an unsupported mode, matchmoded will call switch_to_720p() and change the display to generate an unencrypted 720p image rather than attempt to overlay on top of an unsupported signal.

Incidentally, an early version of matchmoded is still present in the source tree.  matchmode was a binary that used to get invoked when a udev event was triggered, usually by a hotplug event.  Rather than using a lookup table of modes it would query them from the current timing settings in the FPGA.  As such, if you wanted to give 1080p mode a whirl you could compile that, copy it over to your NeTV board, kill matchmoded, and run matchmode a few times until you get stable timing numbers.

Re: Chumby NeTV?

I'd have to clarify the previous post a bit. On some device combos, the link is quite stable and the quality is good. It really depends upon the quality of the transmitter, primarily, and your luck in term of the silicon that's in your box (as would be the case if you were trying to overclock a CPU), and the quality of your cables. Despite the overclocking, I've seen pretty decent results with a number of devices, to the point where sometimes I'll run in 1080p60 for a day and not realize it until I check the timings. FPGAs are pretty forgiving when it comes to overclocking. However, the result is not consistent enough that I'd push it as an "official" feature. It's more of a hobbyist/enthusiast feature.

7BAA 2E53 01C1 DCFF 497B  E7F0 9699 A303 78F0 D9B9

Re: Chumby NeTV?

bunnie, perhaps you should consider a heatsink on the cpu.  it seems as if what you are trying to get the cpu to do do is right on the edge of its tolerance.  I ALWAYS add a heatsink to the cpu's in my routers and accesspoints just in case.  (after all the manufacturer may actually be selling an overclocked product, such as the Linksys wrt320N which is supposed to be clocked at 300mhz but Linksys is selling clocked at 354 mhz!!!)

Just look at the Fon 2100 (La Fonera).  That was designed so badly they had to put a heatsink on it, even though atheros practically gave them a reference design which needed no external cooling.  They fixed it in the fon2200 and fon2201.

I know it would increase the size and price but if it would increase capability and usability it might be worth it...

Re: Chumby NeTV?

bunnie wrote:

It really depends upon the quality of the transmitter, primarily, and your luck in term of the silicon that's in your box (as would be the case if you were trying to overclock a CPU), and the quality of your cables.

So If my transmitter works perfectly with my tv with the 1080p60 frame rate then netv clocked to 1080p60 should also perfectly retransmit the signal, right? Because it would be connected to the transmitter with the same cable which is usually goes to the tv. And if the incoming signal is OK then the outgoing signal should also be OK. And if it is not then it is definitely would be netv problem.

Apart from that I like the device and would give it try anyway