Hot Wheels Radar Gun serial interface

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I posted a project yesterday showing how the Hot Wheels Radar Gun works and implementing a serial interface for it. Since that time a double epiphany has struck me, one for an easier way to interface it and the other for a slight bug in reading the radar.

If perchance you have downloaded the code and actually plan to use it, you may want to get the latest version when it's posted (the next day or two). Depending on how the spirit moves me, I may include more detailed instructions on the easier interface, but don't hold your breath. All the other information is correct as far as I know, and the bug only affects using the radar in pulsed mode, not in steady mode.

Sorry about that. They say the ancient temple builders used to consciously incorporate mistakes so as to not offend god. Probably what I was doing, too.

Bug fixed. If you want to know more about the alternate modification, post here and I'll describe it.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd like to know?
Chuck let us know here when you post the new version too!!!

Thanks
John

Resistance is futile…… You will be compiled!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The new version is posted. That's what the "bug fixed" edit is above, but maybe it isn't exactly clear that it means it's been reposted. It's only about 3 lines of code different.

As for the mod: In the original there's an LCD which is just the glass, with the ATmega88 providing all the timing, etc. It needs 4 lines for the backplanes, and 8 for the segments, for a total of 12. Unfortunately the RxD and TxD are two of the 8. The ISP lines (MOSI, MISO, and SCLK) are three of the 4 backplane lines. All 4 have resistor networks attached to them so they can generate V/2, but this does not interfere with the ISP programming.

There is an ADC used to test the battery level which goes to an ADC which shares a general I/O pin. Meanwhile, there are 2 ADCs which are unused, and these are not general I/O pins. Finally, there is an "unused" pin which goes to a test point (pad) which has a resistor to ground.

In my original mod (which is what the software is written for), I removed the test point's resistor to ground, thereby freeing up one I/O pin. I moved the battery's ADC line to an unused ADC, thereby freeing up another I/O pin. I then moved the LCD lines that were on RxD and TxD to these two pins, thus freeing up the USART. It was tedious, nasty, and a pain to do these changes since I don't usually spend my spare time writing Genesis on a grain of rice.

The epiphany I had later was that a standard LCD (HD44780 in its various configurations) needs 7 pins when operating in 4 bit mode. When you remove the radar gun's LCD glass, there's a nice row of pads easily accessible. Two of those pads are the RxD and TxD lines, free and clear. Six of those pads are the other LCD data lines, and they are also free and clear. Four of the pads are the backplane leads, but they have the resistor networks attached to them.

But, if you remove the resistor to ground on the test point (easily done), you get your 7th line for the HD44780. The pads can be reached with normal sized fingers and soldering irons, and there is no trace cutting or resultant kicking the dog.

Then to my code: you throw out the interrupt handler (no need to generate those bizarre LCD waveforms) and its initialization code, change the command language a little, and rewrite the LCD output routine, and kazoom! You have a 16x2 (or whatever) output instead of 4 characters. Of course you'll probably have to spell out "battery low" instead of showing a broken battery symbol, but hey, be flexible.

Implementation is left as an exercise for the student.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chuck your instructions and explanations are the best and you always manage to make me laugh with insights like: "It was tedious, nasty, and a pain to do these changes since I don't usually spend my spare time writing Genesis on a grain of rice."

This is a really cool project Chuck!
Thanks,
John

PS:
If you’d like to download Chuck’s awesome Radar Gun project here’s the link http://www.avrfreaks.net/index.p...

Resistance is futile…… You will be compiled!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I heard about these guns, I went out and bought one, pulled it to bits and posted a bit of info. That's as far as I got. When I spied your project, I just had to have a look - good stuff. I might just be motivated to pull mine out again (it never got re-assembled!).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am slightly lost. Where can I find the header files you code uses? e.g. macros.h, eeprom.h, iom88v.h. I have looked in my winavr distribution but they are not there. Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, it's written for ICCavr, not winavr, so they don't exist exactly. There will be the equivalent to iom88v.h, which is the ATmega88 header file. The eeprom.h file just lets you read and write EEPROM, so it should be easy to fake.

Someone familiar with winavr (oh, Cliff) can give you more details.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can try the demo of iccavr for the time being. Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
There will be the equivalent to iom88v.h, which is the ATmega88 header file.

Not exactly. You would include and set the the ATmega88 in the makefile (or the project options if you use AVR Studio).

There are equivalent EEPROM utilities in avr-gcc, though the specifics may differ.

For macros.h, it depends on what is in that file. There are probably equivalents for much of it in avr-gcc, or they can be created easily (or possibly just copied straight from it).

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Not exactly. You would include and set the the ATmega88 in the makefile (or the project options if you use AVR Studio).

Thanks, Steve, for the post. I never touch the stuff myself, so this is news to me.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I've just finished the last of my exams for the year today and now have three months off, if you send me the code I'll be happy to port it to GCC for you. Don't have a radar to test it on, but I can do it on the code alone.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know if dgabler wants to have you port it or not, but the code is posted as a project here.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was working on extending the code to work slightly different. I hope I can get it to work :) Thank you for the offer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

having some issues. Hoping I can get some direction. Hardware setup: same as OEM but Resistor at C5 has been removed.

Modified code:
radar_lcd.c:
timer0_compa_isr()
set PORTD = v and commented out PORTC fun.

radar.c:
init():
DDRC = 0x30; // output are powerhold and c5 now.
DDRD = 0xFF; // all ddrd output lcd (OEM)
commented out usart init and sub's in radar.c and radar_io.

I can get the lcd to display my numbers, which is good. I can not seem to read the radar though. In my main() I
int v;
init();
power(1);
v=read_adc(0);
num_out(v);

The program never passes reading the adc. If I tell it read_adc(3) it passes through that function.

Any thoughts what I am screwing up?
edit: I have not set any fuses other than any which may be done automagically
Edit2: Odd I can read non pulsed but when I go pulsed waits forever for radar to "turn on"-> while (PORTB & 0x04);

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dgabler - I'm sorry, but I just now (Dec 20) saw this post. Somehow I must have deleted the email notification for it when it came in on the 5th.

Anyway, I'll be happy to help if I can - what's your present situation with it?

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just bought one from Germany and seems that it has slightly different connections than US version. At least trigger and battery level has been connected to different ADC. Radar frequency is also different 9,5xx GHz.

Ps. That code doesn't compile. It has incorrect prototype for fire_radar() (it is radar() which is a global variable).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AllN wrote:
Chuck your instructions and explanations are the best and you always manage to make me laugh with insights like: "It was tedious, nasty, and a pain to do these changes since I don't usually spend my spare time writing Genesis on a grain of rice."

This is a really cool project Chuck!
Thanks,
John

PS:
If you�d like to download Chuck�s awesome Radar Gun project here�s the link http://www.avrfreaks.net/index.p...

I like this buddy. Thanks for the instructions :idea:

ArcticSoul
Industrial Electronic Engineering, College Student