Well, I don't actually use GPSapp, but I could if I wanted to, so..

My wish is for a North American radio station database (just a flat file in reality, not a bloated cross-indexed bememoth) with approximate GPS coordinates for the transmitters. Then have GPSapp present a menu on demand of nearby stations to choose from, and have it program the tuner for the chosen station (which could be done simply by injecting appropriate button presses if need be).

-ml

Hmm, I just found something very interesting. The FCC seems to have all the registration stuff on-line, and it contains a lot of useful information,

WRCT PA PITTSBURGH USA

Licensee: CARNEGIE-MELLON STUDENT GOVT. CORP.
Service Designation: FM 'Full Service' FM Station or Application
202A 88.3 MHz Licensed
File No.: BLED -19931202KB Facility ID No: 1
CDBS Application ID No.: 192608

40 ° 26' 39.00" N Latitude
79 ° 56' 37.00" W Longitude (NAD27)

http://www.fcc.gov/mb/audio/fmq.html

Very cool.. just think what we could do with it.. a special radio-info screen (courtesy of Hijack) to display the station name etc.. by just doing a lookup based on the currently tuned radio freq.

Cheers

Neat idea! I like the radio-info-screen idea. Know what I think would be best? Write a third-party application, independent of GPSapp, which did the following:

- Reverse-engineer the storage format of the scratch partition (we've been told that it's pretty easy to figure out if we but try).

- Locate the place on the scratch partition where the radio station presets are stored.

- Every ten minutes or so, briefly check to see if it's getting lat/long coordinates from the serial port. Connect only long enough to grab one set of coordinates, then free up the serial port again.

- Database lookup the ten or twenty closest stations.

- Write those to preset bank "C" (or optionally banks B and C for 20 stations) on the scratch partition.

So, in a totally transparent fashion, you always have a bank's worth of the nearest stations ready to go just by hitting the bank button on your remote. If done right, it wouldn't even interfere with GPSapp. Or it could cooperate with GPSapp. Or heck, I guess it could be part of GPSapp if you wanted it to be as long as it was off by default.

Perhaps a 'signal strenth' reading based on the location and the power of the station and/or height above surroundings? Both of these pieces of data are also available. Here's the output for one of my favorites:


WEQX VT MANCHESTER USA

Licensee: NORTHSHIRE COMMUNICATIONS INC.
Service Designation: FM 'Full Service' FM Station or Application
274B 102.7 MHz Licensed
File No.: BLH -19850426KD Facility ID No: 49706
CDBS Application ID No.: 77913

43 ° 09' 58.00" N Latitude
73 ° 06' 59.00" W Longitude (NAD27)

Polarization: Horizontal Vertical
Effective Radiated Power (ERP): 1.25 1.25 kW ERP
Ant. Height Above Average Terrain (HAAT): 759. 759. meters HAAT
Ant. Radiation Center Above Mean Sea Level: 1219. 1219. meters RCAMSL
Ant. Radiation Center Above Ground Level: 53.0 53.0 meters RCAGL

Not directional
Site in Canadian Border Zone Distance to Border: 205 km


-Zeke

(I can imagine the government's concern when we ask for the full radio station database so we can use it with Hijack...)

Yeah, I actually found the raw database data on the same site, http://www.fcc.gov/mb/databases/cdbs/. It is a bit of bit banging to turn it into a nicer format, but it isn't too hard to create a file with latitude,longtitude,callsign,frequency,FM/AM information.

A separate app is probably best, it might just get the current location from gpsapp. Eventually it is probably useful to split gpsapp into a backend that continuously monitor the serial port (similar to gpsd) and separate frontends that run only on demand.

Eventually it is probably useful to split gpsapp into a backend that continuously monitor the serial port (similar to gpsd) and separate frontends that run only on demand.

This makes me think.

What if Hijack exposed a new device in /proc somewhere that was just another hook into the serial port. But it did so in such a way as to always allow multiple applications to connect to it simultaneously without locking it? Then multiple apps could use the serial port without worrying. It could be named something special like "freeserial".

Or does it already do this and I just don't understand how it works?

To combine a couple of the ideas here, how about a Hijack api which allows a user app to publish an arbitary entry in /proc with certain information that might be usable to other user apps. Like gpsapp could tell Hijack to create a /proc/gps which would contain the current coordinates and whatever other information might be relative to apps that might want that info. Sort of like /proc/empeg_notify, except that user apps can control the contents of the /proc entries.

Useful? No?

It is a bit of bit banging to turn it into a nicer format, but it isn't too hard to create a file with latitude,longtitude,callsign,frequency,FM/AM information.

Why bother re-formatting it at all? Just grab the file as-is and put it on the empeg, then have the app Do The Right Thing to read the data it needs.

We talked about this before, I never did anything about it, but my thoughts were more along the lines of replacing the presets as you moved about.

How do you communicate between the backend and the frontends? Realize I'm still one of the maintainers of gpsd, so instead of being "like gpsd" we could just make gpsd bow to our wishes.

WRCT PA PITTSBURGH USA

God, that's a horrible station

Licensee: CARNEGIE-MELLON STUDENT GOVT. CORP.

I guess they didn't get the memo that the dash was dropped. (Or they did and didn't do anything about it.

I haven't looked, but possibly, to save space.

I really doubt that's necessary though.

We can already connect multiple apps to the same serial port. However, we need to send initialization sequences for some GPS receivers. Also, when multiple processes are reading the serial port, they steal bytes from each other. In the end noone might even get a complete packet to decode, or one app 'starves' all others from position updates by reading more agressively.

Ah, just as I suspected, then, I didn't understand how it works.

Why bother re-formatting it at all? Just grab the file as-is and put it on the empeg, then have the app Do The Right Thing to read the data it needs.

Because it is about 187 MB worth of data. For all AM, FM and TV stations, with the complete history of 'application/renewal/adress changes' and data about who the registrants are etc.

Then there is information about what antenna is used, what the stations output power is, whether it is a directional antenna and the observed strength in various directions. And there are a bunch of stations that are not active anymore, or have no coordinate information.

My guess is that i99% is useless for our purposes and from what I can tell we would end up with less than about 2-3MB of data, which will be trivial to seek through even when we don't have a fancy index.

How do you communicate between the backend and the frontends?

If we bring up the loopback network device, we can simply use a tcp port. I figured that gpsd was using floating point calculations and in the end still output NMEA, so we would end up parsing the NMEA data twice.

You don't technically need to parse the NMEA again unless you wish to. If gpsd lacks the data you wish in its simple command set, we've added things before.

And I thought there was a reason you wanted to avoid bringing up the loopback but maybe I'm mixing things up.

So how about we teach Hijack to parse NMEA.. it could then just monitor everything incoming on the serial port, and when it recognizes valid NMEA strings, just update /proc/nmea or some such virtual file, while still passing everything along the serial chain as normal..

Then we'd need a GPSapp backend to do the "initialization of specific GPS units" when needed (not needed for my GPSr). And the GPSaapp front end could still run the way it does now, soaking up GPS input from the serial port. Or it could get it's data from /proc/nmea. And the new Radio station locator app could also grab data from /proc/nmea, and I suppose from /proc/empeg_tuner or some such thing which provides the current tuner station info (91.5Mhz FM).

??

And I suppose an added extra from /proc/nmea is that Hijack could then correct the time-of-day using the might of the US military as a simple clock reference.

And I suppose an added extra from /proc/nmea is that Hijack could then correct the time-of-day using the might of the US military as a simple clock reference.

Oooo, I like this!

So how about we teach Hijack to parse NMEA

Ew. It would work, though.

Sure it would work.

But it wouldn't be able to handle TSIP, or any other non-NMEA gps protocols. And it would be a pain if someone connects his GPS to a different serial line (i.e. the tuner serial), or to the gadget with multiple serial ports that genixia (or was it someone else?) is working on.

We could even teach Hijack to read and draw tiger/line map data and reprogram the radio presets. But at some point the question becomes, why would we? There is a fully functional user space that makes it easier to debug, keep things modular. I am a klutz with games so I never play breakout, why is it using up precious bytes of kernel memory (I must admit it is really amazingly tiny).

I would more likely suggest to move some thing out of Hijack, breakout, calculator, vital signs, perhaps even some of the configuration settings.

But I've been thinking about how to communicate between frontends and the backend. The best way I could think of is to have a shared mmap, the backend simply updates a 'struct gpsdata' and the frontends can poll this at their own leasure. However, as everything is mounted RO we can't use a regular file to mmap. We either have to mount a ramfs/tmpfs (is that available in the empeg kernels?) or have hijack expose a mappable file without backing store through /proc.

HiJack could also parse TSIP. But I think the gpsd-like route is better.

Why not have the equivalent of struct gpsdata that can be marshalled and unmarshalled and read it on request through a socket?

The thing I'm wondering is if you'll scare away further third party authors with mmap...

Of course, it may be for this application that you and I will be on the only third party authors, and I guess it's safe that neither of us care.

Things get put into Hijack mostly because I find them useful on my player, and/or significant numbers of others want them.

Breakout is there simply because it is cool, and has existed since v2 of Hijack (v1 had Pong instead).

But I do like the idea of removing all the stuff that needn't be there, specifically everything that I do NOT use on my player:

-- audio overlay
-- bass/treble adjust
-- EXEC, EXEC_ONCE
-- XML for the web interface
-- audio mute support
-- RDS enhancements
-- /proc/empeg_display.{raw,png}

These could save me a fair bit of buffer memory, and I have NEVER needed any of them.

Cheers

Don't panic.. I'm not about to scratch all of those.

But I really would like to be able to get some benefit from the HUGE amount of code devoted to the XML interface and the /proc/empeg_display.{raw,png} support. Currently, the XML stuff is still MicroSnot-only, and I'm a Linux guy.

-ml

Is there anyway you could setup config settings for each of those features. So we could turn them off. I also do not use the web interface. So the XML, empeg_display.raw|png, and the rds enhancements i don't use. I'm not sure on the audio overlay, and audio mute support. But i would thing if we could set a on/off config for every hijack option. We could customize hijack for our player, only turning on what we need to use.

Edit: I'm referring to a config.ini setting under [hijack] would be very nice.

A config setting in the kernel's make config would be kind of cool, too. That's about ten-millionth on a list of priorities, though.

-- EXEC, EXEC_ONCE
Hopefully after adding 'EXEC_MENU'

-- audio overlay
-- bass/treble adjust
-- audio mute support
I don't know how much of this can be done from userspace, but with a 'fake' audio-device a userspace app should be able to do this. esd, is doing similar things on my desktop.

-- /proc/empeg_display.{raw,png}
Hmm, makes me think. Perhaps I can create a little proc-foo that allows an application to pin a couple of pages in memory which can then be mmap-ed/written/read from userspace. Similar to how I'd like a gpsapp frontend to talk to a gpsd backend. Maybe I should just pull ramfs into whatever kernel version the empeg is using.

- audio overlay
-- bass/treble adjust
-- audio mute support
I don't know how much of this can be done from userspace, but with a 'fake' audio-device a userspace app should be able to do this. esd, is doing similar things on my desktop.

LD_PRELOAD would be fun for this except I think the player app isn't dynamically linked.