Radar Detector...

[NaterGator]

Have you guys seen/tried trapster? Not perfect, but neat. Lets you report GPS location of speed traps, red light cameras, etc... as well as get alerts when you approach these GPS locations.

I was unaware of it. I sent them an email to see if they are interested in possibly integrating radar detector connectivity over bluetooth with me.

I can do the server side software fairly easily, but if trapster shows an interest in this functionality and I simply pass standard data over RFCOMM to the software and handle various radar detectors in hardware only (IE: abstract everything through the hardware so software only deals with a single unified interface) it would be easy for them to 'do their own thing' so to speak.

I'm not immediately aware of other detectors on the market that have similar remote displays (or a data output of any type, for that matter) because I don't own one, but if they exist I'd like to be able to reprogram the AVR via bluetooth and select which type of detector to "read" from the software interface. The goal is to create one piece of hardware you connect whatever detector you want to.

I should be getting the bluetooth radio and various prototype parts this week so I'll start building soon. If things go well and people show interest I'll work it into a production ready form and order some PCBs and make some housings in solidworks.

Thanks for the tip on trapster.

[NaterGator]

Bluetooth radio/etc arrived today and I soldered this afternoon and it is now together into it's current form:
v1board.jpg

RFCOMM between the AVR chip and my laptop is working flawlessly in linux and I wrote the asynchronous command recognition functionality tonight and tested the unit with a bluetooth controlled variable speed LED (baby steps!) easily across the condo tonight. The range is way beyond what's necessary, so the next step is writing a prototype android app to ensure the RFCOMM is all hunky-dory with the Droid and then I'll polish the app up a little more, finish up the AVR programming to detect V1 signaling and control mute/display on/off status, and wire it up to my V1 and go for a test drive.

I will post updates when there is something interesting to report. And if you're a decent android developer (or even want to get your feet wet) and/or you are good with graphics and would like to help with the GUI elements/layout/design ethos etc, by all means jump on in. Being an engineer (in training) I'm not exactly an artist, so I could probably use a hand in that department

---Nate

[cowboys1]

When I first heard of trapster, I thought it could detect radar. Was disappointed when I found out otherwise. So I'll be looking forward to an app that can actually do this.

[steveninspokane]

I own a Passport 9500ix, and I wouldn't want to connect anything to it that could possibly hinder it's performance. Lidar for the most part is too expensive, and even though there might be a dozen or so operating in your area (depending on the size of the area you live in, L.A, Seattle, Chicago etc...) there will be a more considerable amount of K/Ka Band radar detectors trying to catch you. While using RD's for the 5 years+, I have gotten maybe 10-15 Lidar alerts, most scariest sound in the world, haha. Also, Never speed without a rabbit to follow.

[hondabomdc5]

...in for some results and an app

[Phoxus]

+1 This needs to stay alive. For I love to drive fast without paying for the consequences of Money.

Bring on the death.

[NaterGator]

I decided to take my first foray into Android development tonight. Wasn't so bad... the BluetoothChat example app provided a good bit of insight into android's interfaces, message handlers, intents, RFCOMM intercface, etc.

Right now I have an app that seeks the paired bluetooth device, allows you to connect and disconnect, 4 buttons that allow me to control a blinking LED on the prototype board (blink/stop/faster/slower) and a response output TextView. (Yeah I know, not all that exciting but it proves the response time and command robustness between the two devices which is crucial.)

This is a good start and I'm ahead of where I expected to be. Like I said my graphical skills and GUI layout sense are fairly lacking, but that will wait for another day. It's now a matter of cleaning up the code, programming in a device discovery and pairing activity, setting up a configuration page, setting up an output stage (audio/onscreen visual), and hooking up the detector to see how things work.

All in all moving along nicely.

--Nate

[Phoxus]

I love you Nate.

<3

[1033]

some of the older (2004 maybe) whistler radars with LEDs only had a remote screen you could hook up from inside the radar on a little jack, IIRC it had a wire per led... You could run those directly into an AVR and mount the base out of sight because of the grill mounted remote radar unit/laser detector.

In the meantime Ive been having great fun using RFCOMM chat app to control this SerLCD, great fun...

I would like to add: if you want that arduino running fast you need to hook the radar up on the interrupt pins, the 328 (Duemilanove) only has 2 (witch would work with an OR array). However the ardunio mega might be more help with its 6 external interrupts. Also I think those BT Modems have some GPIO pins... you might be able to cut out the mcu in this project.

[NaterGator]

1033,
So far in my experience the arduino responds quicker than the Droid can update the UI, so I don't think speed is a problem.

The 328 AVR does only have 2 interrupt pins, however the V1 signaling protocol doesn't operate like that anyways. It is always transmitting its clocked signal, so the arduino needs to be syncing, reading a complete frame, transmitting frame changes over RFCOMM, then resyncing and so on. The majority of the time the Droid will not need to send much data to the AVR, except save for a few acknowledgments and the very occasional configuration change, so the Droid can be scanning for the AVR's refresh signal pretty much constantly.

Thus my approach is going to be the following:
In the arduino loop first run a while loop and pulseIn() until the frame start pulse is detected... then read the remainder of the frame from the stream and break the loop. The total frame takes ~48ms to transmit. At that point, if any bits changed (a radar event began, ended, intensity changed, etc) get the Droid's attention and send the changed bits over RFCOMM. From there, start a timer and wait for any Droid configuration commands, otherwise restart the main loop.

Based on the latency I'm seeing on the tests I've been running the time it takes the detector to lock on a problem signal is going to be quite a bit longer than the time it takes the 328 to signal the Droid an event is occurring. It will remain to be seen how responsive Java/the Droid can be, but obviously the point is to convey a radar signature to the user as quickly as possible so if anything comes up it'll have to be addressed.

I didn't know about the whistler models... I'll look into it, thanks.