Thursday, October 27, 2005
Satellite parts and Perl module design
The SIR-ALP1 arrived today from ebay. UPS was 1 day late which hopefully will result in some money back for me.
The replacement part from rush2112.net went in with no problem at all. Sirius radios seem to be designed in two halves - the tuner, a standard component common to virtually every radio, and the UI end. This is confirmed in the sportster, the starbase and the Sirius connect series. Protocol analysis of the data between the tuner and the "front end" has revealed that the protocol is the same in all three of these tuners. It's not a stretch to imagine that every other radio has an identical tuner built in.
I'm starting to look seriously at the module development. I registered an account on Perl PAUSE and am poring over the guidelines and directions. I have two XM modules to base my design on - Audio::Radio::XM::PCR and Audio::Xmpcr. I have reviewed the former first and the code looks good, except for one thing that is nagging me. This design seems destined to be threaded. These Serius tuners are very chatty. Data is going back and forth all the time about all kinds of info - signal strength, what's playing on every channel, the time, and other info (probably the sports scores data). The PCR is similar in this regard. The module I looked at had a monitor method that was designed to be called in a loop. This is sloppy IMO and how efficient could it be? On the other hand, how many modules force threading on you when you instantiate an object? I suppose it could be optional but I'd still like to see some precedent. I need to review Audio::Xmpcr.
The replacement part from rush2112.net went in with no problem at all. Sirius radios seem to be designed in two halves - the tuner, a standard component common to virtually every radio, and the UI end. This is confirmed in the sportster, the starbase and the Sirius connect series. Protocol analysis of the data between the tuner and the "front end" has revealed that the protocol is the same in all three of these tuners. It's not a stretch to imagine that every other radio has an identical tuner built in.
I'm starting to look seriously at the module development. I registered an account on Perl PAUSE and am poring over the guidelines and directions. I have two XM modules to base my design on - Audio::Radio::XM::PCR and Audio::Xmpcr. I have reviewed the former first and the code looks good, except for one thing that is nagging me. This design seems destined to be threaded. These Serius tuners are very chatty. Data is going back and forth all the time about all kinds of info - signal strength, what's playing on every channel, the time, and other info (probably the sports scores data). The PCR is similar in this regard. The module I looked at had a monitor method that was designed to be called in a loop. This is sloppy IMO and how efficient could it be? On the other hand, how many modules force threading on you when you instantiate an object? I suppose it could be optional but I'd still like to see some precedent. I need to review Audio::Xmpcr.
# posted by James Tatum @ 9:42 PM 
