LynxOsaka

[+karri]

Hi guys,

 

I am going for a trip to Osaka next weekend and I found out that my phone won't work there and my phones GPS navigator does not have maps for that area.

 

So what do you do?

 

Well... Google maps provides the charts and my trusty pimped up Lynx will do the display

 

So here it comes.

 

 

 

And here is the application ready to run on your Lynx.

LynxOsaka.zip

 

It still lacks a bit math and my USB GPS <-> ComLynx interface is still in the works.

 

--

Enjoy,

 

Karri

Edited September 5, 2007 by karri

[+karri]

And then to some very interesting trivia about the ComLynx.

 

According to the docs the _only_ available format is 8 bit + even parity + one stop bit.

 

Just for fun I just wrote an interrupting driver for the Lynx that does not care about parity, overrun or framing errors. And voila! It also supports 4800 baud 8 bit + no parity + one stop bit. Which just happens to be the standard format for GPS receivers.

 

Even better. The new Sigmatel bluetooth GPS receiver has an USB port for charging the batteries. On the pin 3 there seems to be a 4800 baud transmission stream at 5V logic levels. Pin 1 is ground.

 

This means that you should be able to just make a cable with a ComLynx socket on one end and an small USB connector on the other end. No other components are needed!

 

But tonight is late. I postpone this test for tomorrow.

 

--

Karri

[Jess Ragan]

So let me get this straight. You turned your Lynx into a GPS system? That's crazy!

(Yet strangely compelling...)

[+karri]

So let me get this straight. You turned your Lynx into a GPS system? That's crazy!

(Yet strangely compelling...)

 

Thank you

 

I just finished the user interface.

 

A button - planning mode, browse targets or (joypad) set cursor to any place

 

B button - GPS on mode, toggle between map view and directional view

 

The directional view will have a large green arrow showing the direction to the target (if you hold the Lynx in front of you as you usually do). It will also have 3 red 7-segment LED's for distance (like 10.5 km) and 3 LED's for speed ( like 120 km/h) (this could be miles also).

 

Anyway the new interface is here:

LynxOsaka2.zip

 

Any ideas for improvement?

 

Oh, and if you know of some cool places to visit in Osaka I could add them to the list of precompiled targets.

So far I know about the main train station, a place for Swing dancing called "Sam and Daves" and "Salsa House Osaka". But it could be nice to include interesting districts like Chinatown, shopping centers, harbor boulevards, good restaurants. What else?

 

I will only be there for a week.

--

Karri

Edited September 6, 2007 by karri

[Emehr]

Nice work! Are you downloading the maps from your computer to the Lynx then? Also, did you have to make any hardware modifications to the Lynx?

[+karri]

Nice work! Are you downloading the maps from your computer to the Lynx then? Also, did you have to make any hardware modifications to the Lynx?

 

I had to compress the maps I downloaded from google using sprpck. The original maps were 436k and I had to squeeze them with the application into 256k. So I had to use only 8 colors.

 

No Lynxes were harmed during the production of LynxOsaka (no hardware changes).

 

--

Karri

[Matthias]

Hello Karri!

 

And then to some very interesting trivia about the ComLynx.

 

According to the docs the _only_ available format is 8 bit + even parity + one stop bit.

 

Just for fun I just wrote an interrupting driver for the Lynx that does not care about parity, overrun or framing errors. And voila! It also supports 4800 baud 8 bit + no parity + one stop bit. Which just happens to be the standard format for GPS receivers.

 

You are right, i'd run also into this problem (that 4800-8-n-1 is standard for most GPS-receivers),

i was lucky that i found an old GPS-receiver (even old at that time, 7 years ago!) which supported

the 9600-8-e-1 the Lynx accepts by default. Unfortunately the GPS-receiver was 3 times as big as the Lynx

and very heavy

Sadly at that time there were no maps available to me which were scaled for the WGS84-system,

nor did i had the know-how to implement the necessary convertion-routines, so my own application

was only able to show you that you were "somewhere in middle Europe"

 

So it's great that you (and we all) are now having more options for such a neat Lynx-application

 

Kind regards

Matthias

[Matthias]

Hello,

 

attached is my own small application "GPS.O" and some GPS-string-examples, you can test this program

by transferring GPS.O to your Lynx using BLL and then send one of the given GPS-string-examples to the Lynx

using a standard terminal program (like Hyperterminal for Windows) with

settings 9600 Baud, 8 databits, Equal parity 1 Stopbit.

After sending a GPS-string use one of the direction-keys on the Lynx to toggle from text-screen to the map-view.

If the GPS-data is understood the position will be marked by a cursor consisting of 2 little black blocks,

the map will stay till a new GPS-string is received.

 

Kind regards

Matthias

Gps.zip

Edited September 6, 2007 by Matthias

[Shawn Jefferson]

That's just neat. Do you have the GPS connection working yet, Karri? Can you post pictures of the whole setup once you get it going?

[Jess Ragan]

Thanks, you've just given me something to post about on my classic gaming blog!

 

http://www.lakupo.com/grblitz/reactivator/index.htm

 

Hey, while you're cooking up fun GPS applications for the Atari Lynx, why not make a port of Pac-Manhattan for the system? If you've never heard of it, imagine a real-life game of Pac-Man where one player is being chased by four others, and you've got the right idea.

[+karri]

That's just neat. Do you have the GPS connection working yet, Karri? Can you post pictures of the whole setup once you get it going?

 

I have some speed problems with the GPS reception. But the characters are coming in already.

 

Here is a picture of the hardware:

 

The black wire from pin 1 goes to ComLynx ground (the shield).

The green wire from pin 3 goes to the middle terminal (ComLynx Data).

 

I also have a few pictures about the Lynx plus the GPS module.

 

 

I added a small magnet at the back of the Lynx and a small iron strip at the back of the GPS receiver.

 

For adding the Lynx to my bike I also took the connector from an old lamp and added it to the battery cover.

 

But no GPS is really working yet. I have the math sorted out already and the positioning display works now.

 

--

Karri

[+karri]

And here are a few pictures about the Lynx connected to my bike.

 

The lamp connector on the Lynx cover.

 

 

I intend to code in a bit local terrain and take the system out for a spin on Saturday.

 

--

Karri

[sage]

Hello Karri!

 

And then to some very interesting trivia about the ComLynx.

 

According to the docs the _only_ available format is 8 bit + even parity + one stop bit.

 

Just for fun I just wrote an interrupting driver for the Lynx that does not care about parity, overrun or framing errors. And voila! It also supports 4800 baud 8 bit + no parity + one stop bit. Which just happens to be the standard format for GPS receivers.

 

You are right, i'd run also into this problem (that 4800-8-n-1 is standard for most GPS-receivers),

i was lucky that i found an old GPS-receiver (even old at that time, 7 years ago!) which supported

the 9600-8-e-1 the Lynx accepts by default.

 

There is no "default"

9600 is just what is the highest compatible rate for a pc connection. 4800 is just chnaage of one number in the timer hardware. but about the parity i am not sure.

[+karri]

9600 is just what is the highest compatible rate for a pc connection. 4800 is just chnaage of one number in the timer hardware. but about the parity i am not sure.

 

From my bible (42Bastian's site about the Lynx hardware):

Data Format

 

The serial data format is the standard 11 bits. We do not offer a choice.

 

The standard bits are:

 

1 start bit (binary 0);

8 data bits, LSB first;

1 parity bit (or 9th bit as defined by the control byte);

1 stop bit (binary 1).

 

The parity (or 9th) bit operates as follows:

 

Receive:

The state of the 9th bit is always available for read in the control byte. In addition, the parity of the received character is calculated and if it does not match the setting of the parity select bit in the control byte, the parity error bit will be set. Receive parity error can not be disabled. If you don't want it, don't read it.

Transmit:

The 9th bit is always sent. It is either the result of a parity calculation on the transmit data byte or it is the value set in the parity select bit in the control register.

The choice is made by the parity enable bit in the control byte. For example :

 

If PAREN is '1' and PAREVEN is '0', then the 9th bit will be the result of an 'odd' parity calculation on the transmit data byte.

If PAREN is '0', then the 9th bit will be whatever the state of PAREVEN is.

 

We have just discovered that the calculation for parity includes the parity bit itself. Most of us don't like that, but it is too late to change it.

[+karri]

Bad news...

 

The Lynx hardware is not really fit for receiving at full speed. If I keep a small pause between characters or use 2 stop bits I can go full speed with the data. In the docs they mention 8,e,1 and I know that it works for the downloader. I don't remember if I had to add delays into that code to get it to work.

 

But receiving 8,n,1 stuff without breaks just does not work. I have to chicken out for my trip to Osaka and go there without my GPS.

 

But I'll be back.

 

--

Karri

[EricDeLee]

That's pretty cool! Hey... pick me up some PCE HU cards over there!

[Gregory DG]

Very cool project!

[semicolo]

I think you can't receive 8,n,1 contiuously because there's a bit missing, you'd have to use 8,n,2 to be able to skip the parity bit, else the lynx hardware mixes the stop bit with the parity bit and the following start bit is probably causing a framing error, because it should be a stop bit.

[+karri]

I think you can't receive 8,n,1 contiuously because there's a bit missing, you'd have to use 8,n,2 to be able to skip the parity bit, else the lynx hardware mixes the stop bit with the parity bit and the following start bit is probably causing a framing error, because it should be a stop bit.

 

Yes. That is my conclusion also. I managed to do it in my PSP. But I would really like to do it on the Lynx also.

 

So this leads to the next question:

What is the best way to fix the problem with interfacing the GPS receiver to the Lynx?

- separate hw converter cable (small microcontroller with a single UART, receive from the GPS, transmit to the Lynx)

- find instructions for using 2 stop bits in the GPS unit (may be difficult, may need bidirectional communication)

--

Karri

Edited September 8, 2007 by karri

[semicolo]

what serial options have you got on the gps side ?

since the lynx seems to be stuck to : start, eight bits, parity, stop, maybe you could use a microcontroller to receive from the gps at 4800 bps (for example in software) and send the data back at 9600 bps (with an integrated uart).

[+karri]

While in Osaka I got a great idea of how to fix the problem in SOFTWARE!

 

The thing is that Lynx requires 10XXXXXXXXP1 for each byte sent. When it receives a byte it will set P if the parity is wrong. And it will set Framing Error if the last '1' is a '0'.

 

If we get a framing error we lose all consecutive '0' bits following the '0' that caused the error.

 

So actually we get most of the data right all the time.

 

Instead of receiving a byte I write the driver to read in 11 bits in an int.

 

For NMEA traffic I know what to expect so I can read in the message like:

 

waitfor('$');

if (found('G'))

etc...

 

So I just need two received 11 bit elements and then I try to find the right bit-stream and do the matching in sw instead of in hw.

 

Actually I already wrote the code on a sheet of paper

while looking out from my window at the hotel in Kobe. This was the view at 4 in the morning.

 

The code should work with no extra hw.

 

Exciting!

 

--

Karri

Edited September 15, 2007 by karri

[semicolo]

Let us know if this works, hardware only is less pain, but when you've got no choice ...

[+karri]

Let us know if this works, hardware only is less pain, but when you've got no choice ...

 

I wrote a driver that works on simulated GPS data on a real Lynx. It was kind of tricky to design but also fun. In some cases you may lose up to 5 bits from every character. But my driver saves what it reads in memory. And on the next round it uses the previous reception and the NMEA standard for guidance. So actually it seems to work perfectly.

 

But then i also noted that my Bluetooth GPS worked on 38400 bauds instead of 4800. So I went shopping for a cheap GPS mouse on eBay and got one Holux GR 213 unit.

 

The good thing is that it has no battery. And it is based on the Sirf III chip. And it was only 23 USD's.

 

While waiting for it to arrive I decided to make a new cable for it.

 

 

The cable is an USB extension cable that I cut in half. All USB cables should have 4 wires in them:

 

- black = ground

- white = D-

- green = D+

- red = +5V

 

This time I also need to pass power from the Lynx battery to the GPS mouse. That is why the red wire is also needed.

 

 

For the ComLynx I need only black, green and red.

 

- black = shield

- green = middle terminal

- red = tip

 

 

Now I just have to wait for the Holux module to arrive.

 

--

Cheers,

 

Karri

Edited September 27, 2007 by karri

[+remowilliams]

Okay, this is insanely Atari techno nerd cool.

[+karri]

Okay, this is insanely Atari techno nerd cool.

 

Thank you!

 

I have also set up a homepage for my project at http://kosh.dna.fi/lynxgps

 

If I ever get it going properly then that is the place from where you can get your map data to feed the Lynx.

 

--

Karri

 

PS. Before you rush out and buy GPS mouse modules. Be sure that they have real serial output.

I believe that Holux 213 with the PS2 plus USB is OK.

The same seems to be true for several Bluetooth devices with mini USB connectors.

 

A real USB-only will talk at 1.5MHz which is not possible for the Lynx.

Edited September 28, 2007 by karri