I just spent a number of hours on a pleasant saturday morning trying to work out exactly why MythTV doesn't get program info for Channel Nine (in Sydney, Australia). I already knew this was because Mythtv was failing to parse the EIT data, and in particular, the SDT wasn't being found.
After a fair bit of poking around, re-learning the fragments of DVB that I have long since forgotten, compiling various hacks into mythbackend, I eventually worked out that it was looking for the SDT in the wrong transport ID.
Because mythtv (being the bastion of stunning design that it is), stores a NIT/TID (network id, transport id) per channel, and _also_ stores a TID into the multiplex table. So the channel table has lots of very fine NIT/TIDs which I checked until the cows came home, before eventually discovering that the code was also reading from the dtv_multiplex table.
One "update dtv_multiplex set transportid = 1056 where mplexid=24;" and I now have program schedules for channel 9. w00t!
Ok, this is a pretty trivial thing, and I don't actually care about the data: It's just that this has been non-working for many months, and every time I noticed it it irritated me that I didn't know why it was broken.
Now I do. So now I'm happy :)
Saturday, August 21, 2010
Monday, January 11, 2010
Another thing to add to the list of "Life is too short".
Attempted to add an SVN project from http://code.google.com/p/project into Eclipse using the SVN plugin. Project is an android project.
Total failure. Eventually I got down to errors like:
Noting that there were a project called 'android-l2tp-tether'...
Eclipse is just too big, too clumsy, and too opaque to usefully debug. I wasted an hour wandering around with straces et al, but realized I was just wasting time. Copying the svn directory else, and then doing 'create new project from existing source' was instantly successful. ugh.
Attempted to add an SVN project from http://code.google.com/p/project into Eclipse using the SVN plugin. Project is an android project.
Total failure. Eventually I got down to errors like:
java.lang.IllegalArgumentException: Path must include project and resource name: /android-l2tp-tether
at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63)
at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:1628)
at org.eclipse.core.internal.resources.Container.getFolder(Container.java:137)
at com.android.ide.eclipse.adt.internal.build.PreCompilerBuilder.buildAidlCompilationList(Unknown Source)
at com.android.ide.eclipse.adt.internal.build.PreCompilerBuilder.build(Unknown Source)
Noting that there were a project called 'android-l2tp-tether'...
Eclipse is just too big, too clumsy, and too opaque to usefully debug. I wasted an hour wandering around with straces et al, but realized I was just wasting time. Copying the svn directory else, and then doing 'create new project from existing source' was instantly successful. ugh.
Saturday, January 9, 2010
Unit tests
Gradually coming up to speed on gtest (google c++ unit test framework). Yes, I'm know I'm painfully behind...
And retro-fitting unit tests to existing code isn't much fun. However, it is entertaining for the number of latent bugs it finds! There's always something special about output like:
Noting that the unit test in question creates an unparametrised object and inquires as to it's size. :)
Off to fire up a debugger and find out wtf is going on.
And retro-fitting unit tests to existing code isn't much fun. However, it is entertaining for the number of latent bugs it finds! There's always something special about output like:
[----------] 2 tests from Image [ RUN ] Image.Empty Segmentation fault (core dumped)
Noting that the unit test in question creates an unparametrised object and inquires as to it's size. :)
Off to fire up a debugger and find out wtf is going on.
Sunday, November 15, 2009
Bayes and models.
This is me talking to the pumpkin (aka thinking aloud).
I have two models.
One is that everything is noise, and has a discrete distribution over a grid.
One is that there's a pattern and predicts the future location of an event.
Bayes says the posterior probability of the model is:
P(M|E) = P(E|M)P(M) / P(E)
where
P(E) = P(E)P(M) + P(E)P(!M)
Ahhh. I realise my mistake. P(E) is not the ideal probability of the event, but the much more restricted 'probably of event in the space the P(E|M) is measured '.
In my case, where the distance between the predicted location and a movement event is being considered, the underlying distribution is the expected distance to a movement events, independent of the model.
I.e. Have no model. Just measure the expected distance from random points to movement events to build the model. Then seperately build the same model specifically for known model conforming events. That generates P(E) and P(E|M).
Doh. For some reason that took a very long to sink in.
I have two models.
One is that everything is noise, and has a discrete distribution over a grid.
One is that there's a pattern and predicts the future location of an event.
Bayes says the posterior probability of the model is:
P(M|E) = P(E|M)P(M) / P(E)
where
P(E) = P(E)P(M) + P(E)P(!M)
Ahhh. I realise my mistake. P(E) is not the ideal probability of the event, but the much more restricted 'probably of event in the space the P(E|M) is measured '.
In my case, where the distance between the predicted location and a movement event is being considered, the underlying distribution is the expected distance to a movement events, independent of the model.
I.e. Have no model. Just measure the expected distance from random points to movement events to build the model. Then seperately build the same model specifically for known model conforming events. That generates P(E) and P(E|M).
Doh. For some reason that took a very long to sink in.
Thursday, July 30, 2009
HAL sucks
So you have a touchscreen, and a 'modern' X11 installation.
Your 'modern' X11 knows that actually configuring devices is something that people who live in caves do. 'Modern' X11s use HAL!
Unfortunately, the nice 'modern' X11 installation is borked. It's talking to HAL which is telling it to use inputs/event0. Which doesn't actually exist.
So the question is: How do you tell it to use /dev/inputs/event2 which is a working touchscreen?
Ahh, you might ask. What you really do is spend far too much time searching google and eventually arrive at:
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="input.product" contains="Touchscreen">
<merge key="input.x11_driver" type="string">evdev</merge>
<merge key="input.x11_options.SwapAxes" type="string">true</merge>
<merge key="input.x11_options.InvertX" type="string">true</merge>
</match>
</device>
</deviceinfo>
Which you install in /etc/hal/fdi/policy/touchscreen.fdi
Of course. it was obvious from the very start that this was the thing to do, no? And the documentation has zero mistakes or misspellings in it. A remarkable end it achieves by being non-existant.
Your 'modern' X11 knows that actually configuring devices is something that people who live in caves do. 'Modern' X11s use HAL!
Unfortunately, the nice 'modern' X11 installation is borked. It's talking to HAL which is telling it to use inputs/event0. Which doesn't actually exist.
So the question is: How do you tell it to use /dev/inputs/event2 which is a working touchscreen?
Ahh, you might ask. What you really do is spend far too much time searching google and eventually arrive at:
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="input.product" contains="Touchscreen">
<merge key="input.x11_driver" type="string">evdev</merge>
<merge key="input.x11_options.SwapAxes" type="string">true</merge>
<merge key="input.x11_options.InvertX" type="string">true</merge>
</match>
</device>
</deviceinfo>
Which you install in /etc/hal/fdi/policy/touchscreen.fdi
Of course. it was obvious from the very start that this was the thing to do, no? And the documentation has zero mistakes or misspellings in it. A remarkable end it achieves by being non-existant.
Sunday, July 12, 2009
Rust as far as the eye can see.
Having many adventures trying to compile a new kernel for the DevKit8000
embest haven't submitted the board support to mainline and after reverse engineering their patches, it's easy to see why!
The diff is littered with random patches to random files (that aren't used), #if 0'ed code, and cruft like:
Which brings me to a confession: I just realized it's been something like 3 years since I last ran 'make menuconfig' on a linux kernel. The rust! It burns!!
embest haven't submitted the board support to mainline and after reverse engineering their patches, it's easy to see why!
The diff is littered with random patches to random files (that aren't used), #if 0'ed code, and cruft like:
#ifdef CONFIG_OMAP_MUX_DEBUG - debug = cfg->debug; + //debug = cfg->debug; + debug = 1; #endif warn = (orig != reg); - if (debug || warn) + //if (debug || warn) printk(KERN_WARNINGIt's been about two hours work to separate out the parts that actually do something, and port them forward to a 2.6.30 kernel.
Which brings me to a confession: I just realized it's been something like 3 years since I last ran 'make menuconfig' on a linux kernel. The rust! It burns!!
Saturday, July 11, 2009
DevKit8000
I recently ordered a DevKit8000 development board for use in an embedded image processing project I'm looking at.
My DevKit8000 arrived yesterday. I bought the "yes, I will have fries with that" version, so it has the 7" touchscreen, more cables than you can poke a stick at, 512MB sd card, a USB hub, and 2 power wall-wart power supplies.
Total cost was $AUD420 including DHL shipping of ~ $AUD80. The price for the board board is comparable with the BeagleBoard, but the shipping was cheaper and easier from China than it would have been from DigiKey! So I'm pretty happy with the price.
One of the power supplies has a USA plug, the other is something European.
The one with the USA plug is apparently the board power supply, the other is probably the USB hub power supply (at least, the plug doesn't fit the board).
The board itself had Windows CE loaded in NAND flash out of the box, which sent me on a 4 hour trail of destruction trying to replace it with linux. This was mostly due to me not realising that the sd-card that comes with the board is junk, and in addition to being unreliable, doesn't function at the 3.3V the OMAP processor requires for it to be booted from.
Not realising that, I thought that I must be doing something wrong (which given the .. umm.. erratic number of the board documentation wasn't unlikely) and so tried all sorts of things in an effort to re-flash the NAND X-loader, cumulating in formatting the NAND flash and rendering the board entirely unbootable. Waving aside the blue air, I finally did what I should have done to start with, and use a known-good SD card. Which instantly booted correctly, taking another 2 minutes for me to reflash the x-loader, u-boot, uImage and filesystem. *&^*&^*&^&*!!!!!!!
With the board actually booting and running linux, it was much more useful. It immediately come up on the ethernet with an ifconfig+route making it a lot faster to move images around than the sd-card sneakernet I had been using.
The CD that comes with it has a port of Android which functions rather well and was useful is checking that the touchscreen actually works.
The hardware appears to be fairly close to the beagleboard, except that it also includes an on-board ethernet, and a ZIF socket for a camera input.
There's a couple of odd things: The host USB port (as opposed to the OTG USB port) appears to be missing a chip. The pattern is there for it on the board, and all the pad have solder on them, just not chip. This is not entirely unexpected: The USB Host port isn't listed in the feature list, and the BeagleBoard people have had trouble getting it reliable.
The more concerning one is that one of the power regulators (TPS73701) has a terrible soldering job done on it. It looks like there may have been a solder mask problem and FAR too much solder paste was dumped on. The tab is swimming in solder, and leads look like they didn't quite reach temperature to fully melt the paste. This is one of a two parallel regulators, and the other one is spotless, so I'm a little puzzled as to what went wrong with this one. Both are running the same temperature so it appears they're both working, it just looks terrible.
Other than that, the rest of the board looks clean and well put together.
Now I'm off to setup a cross compiler environment!
Belated files
Very belatedly getting around to posting these.
The Eagle CAD files for the relay driver board is now posted at https://sites.google.com/a/dgmo.org/home/Home/boards
The Eagle CAD files for the relay driver board is now posted at https://sites.google.com/a/dgmo.org/home/Home/boards
Friday, April 10, 2009
Noise filter your signals!
Free advice. When there's a 200m loop of wire carrying a low voltage signal, noise filtering is a _very_ good idea.
Otherwise the doorbell may ring at 3am in the morning from induced noise...
Otherwise the doorbell may ring at 3am in the morning from induced noise...
Sunday, April 5, 2009
'Fixed' the doorbell today.
The doorbell has been a source of trouble for a while. Mostly because D is in the habit of closing every between where she is and the front door, causing it to be inaudible.
So today, I wired the doorbell between the DCD and DTR lines on the main fileserver and wrote a little C program effectively gets an interrupt when DCD changes. When triggered, this program runs wget to hit a URL on another server, that runs a cgi-bin script, that plays a .wav file through the speaker.
For some reason the name 'Reuben Garret Lucius Goldberg ' kept running through my head...
But the end result is that one can push a door near the front door, and something near the center of the house chimes, so the end goal is fully achieved!
So today, I wired the doorbell between the DCD and DTR lines on the main fileserver and wrote a little C program effectively gets an interrupt when DCD changes. When triggered, this program runs wget to hit a URL on another server, that runs a cgi-bin script, that plays a .wav file through the speaker.
For some reason the name 'Reuben Garret Lucius Goldberg ' kept running through my head...
But the end result is that one can push a door near the front door, and something near the center of the house chimes, so the end goal is fully achieved!
Subscribe to:
Posts (Atom)