Smartphone GPS Tracker Version 1.0

[sti_ffy]

another thing I just noticed about your post was the fact that your rssi led is working. I had to disable the led on my boards because it causes the xsc s3b modules to go into config mode. digi has an app note describing this.

I found the note to which you refer:

https://www.digi.com/support/kbase/kbaseresultdetl?id=3325

The radios we are using are not XSC modules (the note applies to S3/XSC or S3B/XSC - not to S3B/900HP). It is very difficult to keep the various part numbers/firmwares/functionalities straight - they don't make it easy. The preface of the user guide makes this distinction:

Documentation for the XSC firmware is contained in Appendix A. All other firmware documentation in the
manual is not applicable to XSC firmware. Likewise documentation in Appendix A is not applicable to the
900HP firmware.
​

I think the old S3 hardware was XSC only - but now you can buy the new hardware (S3B) with legacy firmware (XSC) such that it behaves exactly like the old radio, or with the new 900HP firmware to run digimesh. Pin 6 is an I/O pin and is apparently programmed by the firmware for different functions in the two firmwares:

______
CONFIG is Pin 6 on the XSC module
__________
DIO10/PWM0 is Pin 6 on the 900HP module (used for RSSI)

 

[Derek]

Yep, pin 6 does seem to vary based on firmware. Up until yesterday afternoon I didn't even realize that digi makes 3 different versions for every type of antenna. Very confusing!

It looks to me like I need to order a few of the digimesh radios. The repeater functionality is nice, but I'm not sure if people will ever take advantage of it, but I guess that is their choice. You can install any module/firmware on the board the suits your needs best.

My pcbs don't have rssi leds so it supports either.

 

[bigredbee]

I"m currently using the XBP9B-XCST and -XCWT modules in the BRB900. I tried to use the x-ctu software to change to from the XBP9B-XC to the XBP9B-DM firmware, but keep getting errors when I try to download the firmware -- has anyone else tried this?

 

[Derek]

I"m currently using the XBP9B-XCST and -XCWT modules in the BRB900. I tried to use the x-ctu software to change to from the XBP9B-XC to the XBP9B-DM firmware, but keep getting errors when I try to download the firmware -- has anyone else tried this?

yeah, I ran into that last night. flip the module over and check the rev printed on the label. it needs to be h or higher to load the dm or mp(?) firmware on it.

the good news is your radios are fine. just load the xsc fw back on and it will fix it.

I wasn't going to ask you which radios you use, so thanks for chiming in with that info!

 

[sti_ffy]

The -002 modules my cuz and I have are rev B. I may get brave and try to load XSC firmware on both of mine at some point - just to see what happens to P2P range. I am curious as to why the DM protocol causes the loss of 8 dbm of receiver sensitivity. There appears to be no reference to why in the manual - or I missed it.

I think the repeater capability, though it is way cool and comes free with the DM modules, is NOT the important point from the recent posts in this thread. Of paramount importance is that everyone who makes one of these trackers - regardless of XBee module type - be sure to configure your radios to transmit only directly to one another (change the destination high and destination low addresses from the default broadcast value). This will prevent lots of grief in the field when inevitably folks' radios happen to be using the same preamble and network ID.

Broadcasting is rude.

 

[Derek]

The -002 modules my cuz and I have are rev B. I may get brave and try to load XSC firmware on both of mine at some point - just to see what happens to P2P range. I am curious as to why the DM protocol causes the loss of 8 dbm of receiver sensitivity. There appears to be no reference to why in the manual - or I missed it.

I think the repeater capability, though it is way cool and comes free with the DM modules, is NOT the important point from the recent posts in this thread. Of paramount importance is that everyone who makes one of these trackers - regardless of XBee module type - be sure to configure your radios to transmit only directly to one another (change the destination high and destination low addresses from the default broadcast value). This will prevent lots of grief in the field when inevitably folks' radios happen to be using the same preamble and network ID.

Broadcasting is rude.

the air data rate for digimesh is significantly greater (10 kbps vs 200 kbps). You can't get something for nothing!

I do agree that we should be changing the addressing so as to not interfere with others.

 

[clairm]

Late to the party I know, but I built something that is almost identical to your version 1.0 last summer. The only changes are:
- Used a tiny single cell LiPo battery to power the transmitter, lasts for about an hour.
- Bought the radio module directly from HopeRF for about $6 a piece (in quantity of 5), the radios from 3DR have a bunch of stuff you don't need and want 5V where the actual radio and GPS want 3V.
- Bought a Yagi for the base station from L-Com for about $40.

I launched my transmitter twice at Hellfire on the Salt Flats, once to about 9,000' and a second time to 11,795'. The first flight I never really lost GPS signal, except a few seconds during boost and it landed about a mile from the launcher.
The second flight lost signal on the way up and again about 1,000' above ground level, with no signal while on the ground. I was still able to drive right to it from the last coordinates. It ended up over two miles from the launch site.

I don't really see the need to explore any other options, at least for my flights.

 

[dickmoran]

Which model transmitter did you use?

Dick

 

[clairm]

The HopeRF HM-TRP operating at 915 MHz. It is the same module as found on the 3DR radios.

This is the Yagi I'm using on my base station. I think the reason I lost signal at the end of my second flight is that we lost sight of the rocket at apogee and it ended up coming down at an almost 90 degree angle to the antenna, which is very directional.

 

[Derek]

I thought about using the hope modules, but I worried that the smt footprint would be difficult for the average diyer to assemble correctly.

All the components I use were chosen so that the board could assembled by the average person. There are some smt parts, but they only have 3 or 5 pins and are pretty easy to solder. The base station may have an 8 pin part. I need to finish that, though.

 

[clairm]

You just solder a header on the HopeRF module and use a cable to attach to the Arduino, or directly to the GPS. I can't imagine anyone with any soldering experience having trouble. It's really no more of a surface mount part than the GPS. I was a bit worried about soldering the SMA connector to the top of the module, since it supports the mass of the antenna during launch, but so far it has been solid. I think having the duck antenna with the pivot built in helps stop any lateral forces from being transmitted down the antenna to the connector.

 

[Derek]

you're right. I was thinking of another rf module I looked at.

how the heck do you buy the hope rf modules though?

 

[sti_ffy]

the air data rate for digimesh is significantly greater (10 kbps vs 200 kbps). You can't get something for nothing!

LOL. I was searching for a somewhat more definitive explanation for the difference. :tongue:

This sensitivity-difference topic really has nothing to do with building or using Derek's GPS tracker configuration (the subject of this thread) so unless you guys want to know what the underlying cause is you can skip the remainder of this post. It isn't my intention to hijack the thread - but I was curious about the underlying mechanism.

---

The answer isn't to be found in the Digi manual, but rather in the ADF7023 Transceiver data sheet. The various modulation schemes require different bandwidths in the IF stage, and of course the narrower the IF stage the higher the signal to noise ratio. Assuming I interpreted it correctly, a 300KHz IF width is required to achieve 200Kbps via GMSK, and the sensitivty at that bandwidth is -100 dBm; while only 100 KHz is required for 10Kbps via 2FSK or GFSK and the sensitivity at the narrower width is -110 dBm.

Although the DM firmware does not seem to provide the ability to switch between these modulation schemes, if someone with a DM-equipped module wanted the extra sensitivity in lieu of the mesh features they could flash the XSC firmware. I have not tested this, but the manual preface shows that both are available for the native DM module without regard for hardware revision.

 

[mikec]

I thought about using the hope modules...

FWIW, I looked at them, but the experience with the diydrones radios suggests the range is less (maybe a lot less) than the XBees, and the module isn't much smaller, so unless you wanted to reduce cost by $20-$30 it didn't seem worth it and I decided to stick with Digi for now.

 

[clairm]

I just clicked on the "add to cart" button on the page I linked above. They got back to me with a quote including shipping. I went back and found the e-mails and it looks like I paid a total of $14.40 for each module, I bought five of them to justify the shipping. Still less than half the price of the 3DR radios, and less mass, lower power requirements, etc.

 

[Derek]

I just clicked on the "add to cart" button on the page I linked above. They got back to me with a quote including shipping. I went back and found the e-mails and it looks like I paid a total of $14.40 for each module, I bought five of them to justify the shipping. Still less than half the price of the 3DR radios, and less mass, lower power requirements, etc.

ok. I saw that but never bothered with submitting the quote. Thanks!

 

[accpool]

Derek, the info on this thread is getting way over my head, but it is still fun. It appears that there is a blending of the V1.0 and the thought of V1.5. is there a way that a V1.5 thread could be started with an updated list of components that will be needed for the V1.5. And if needed maybe a new thread with the other hardware paths being discussed. the only reason i ask is i don't have the Electronics prowess that most of you guys obviously have. I mean no disrespect to all that are posting in their .02 i'm just not smart enough to know which info goes with what

 

[Derek]

Derek, the info on this thread is getting way over my head, but it is still fun. It appears that there is a blending of the V1.0 and the thought of V1.5. is there a way that a V1.5 thread could be started with an updated list of components that will be needed for the V1.5. And if needed maybe a new thread with the other hardware paths being discussed. the only reason i ask is i don't have the Electronics prowess that most of you guys obviously have. I mean no disrespect to all that are posting in their .02 i'm just not smart enough to know which info goes with what

you make a very good point. most of the sidetracking in this thread is my doing and I learned from it, so I think it was extremely helpful.

having said that, I have made a point of keeping the first five posts updated with everything one needs to know to replicate this project. If I have missed something, please let me know and I'll add it to the correct post.

I haven't started a new thread yet because there isn't really anything to post about at this point. once the boards come in and I assemble one and get it running, I plan on creating a new thread. This new project will have a new name as I think the title of this one is a little misleading. the smartphone isn't the tracker and I don't what anyone being misled. The new name is a lot more straightforward.

Derek

 

[sti_ffy]

Derek, you might consider an alternate layout to save more space - like mounting the GPS on the opposite side of the board from the Digi transceiver.

Here is a prototype I assembled using 2 of the SparkFun XBEE Regulated V14 boards stacked one atop the other. The GPS unit is soldered into holes on one of the SparkFun boards from which I removed the XBEE socket. I made sure the holes I chose were isolated from any other components on the board (indicator LEDs, resistors, etc). The fact that both the transceiver and GPS receiver now have their own isolated 3.3v regulator means I didn't need any additional filtration at the UP501. It gets a position lock in less than a minute indoors.

The next step for this layout would be a single double-sided PC board to replace the 2 SparkFun boards, which will reduce the thickness by more than 50%. I think I will keep the dual-regulator approach, as the components are dirt cheap and the results are dramatically better that I was seeing with the single supply - even after filtration.

The idea would be to mount this with the GPS antenna facing away from the avbay sled, or peering through a hole in the avbay sled. An antenna with a section of cable would be preferable, to reduce the mass for isolation-mounting the unit using rubber washers.

I forgot to mention that you must isolate any indicator LEDs or dropping resistors on these prototype boards from the output signal of the UP501. That signal is only capable of sinking a few ma, and the much higher current provided by such indicator devices causes the signal to only swing from 3V down to about 2.7v (instead of much closer to ground). The result is that the XBEE input sees nothing to transmit.

 

[Derek]

I spent quite a bit of time playing with a layout like that. I talk about it a page or two back. I even posted a pic of a xbee board with ublox gps pads on the underside.

I came to two conclusions:

1. Given the size and spacing if the gps module and pins, I couldn't come up with a placement where the gps fits between the xbee pins. if you use smt headers for the xbee, then you could make it work but the board had to be a little wider. Additionally, I don't want to socket the modules.

2. There is no real easy way to mount this assembly to an av sled.

So, I went with the linear layout. Stacking them only saves about an inch in length, but makes the whole assembly more cumbersome.

I've learned years age the driving leds with data lines can cause problems, so I don't do it.

 

[mikec]

So, I went with the linear layout. Stacking them only saves about an inch in length, but makes the whole assembly more cumbersome.

I agree with Derek. Also, you have to put the battery somewhere. And I use wire antennas because the dipoles and RP-SMA are pretty heavy. On the other hand, if you just bubble-wrap the whole package the stacked form factor might have some value.

As for sharing regulators: FWIW, I've tried it both ways and not seen any clear difference, but when you don't get good GPS performance, it's hard to say why -- could be EMI, bad ground plane, power noise, etc. The system I've had the most luck with uses an XBee Regulated board and a Venus 6 board (both from Sparkfun) with only the regulator on the Regulated board powering everything, and it works fine.

 

[sti_ffy]

I agree with Derek. Also, you have to put the battery somewhere. And I use wire antennas because the dipoles and RP-SMA are pretty heavy. On the other hand, if you just bubble-wrap the whole package the stacked form factor might have some value.

Antenna mass is not a significant issue in my case. I plan to install this into a big rocket. You will probably trade mass for range when using a wire antenna in lieu of the dipole. Have you done any range testing? I'd be interested to know what sort of range that antenna provides. We've only tested out to ~550m so far, but the signal was perfectly readable at that range with the transmitter in a fiberglass nosecone lying on the ground, and the same dipole antenna at the base inside a RAV4.

As for sharing regulators: FWIW, I've tried it both ways and not seen any clear difference, but when you don't get good GPS performance, it's hard to say why -- could be EMI, bad ground plane, power noise, etc. The system I've had the most luck with uses an XBee Regulated board and a Venus 6 board (both from Sparkfun) with only the regulator on the Regulated board powering everything, and it works fine.

The Digi Transceiver states 290 ma max when transmitting. The UP501 claims no more than 40ma while searching for sats, and 25 when locked. My first prototype shared the regulator on a single Droids XBEE Simple board (which is capable of 400ma). Together the devices require ~330 ma, but the Simple board has two bright LEDs on it (RSSI and ASSOC) for which the consumption is unknown. Even after adding filtration, the lock time was fairly long. I used very heavy gauge wire to provide power and ground to the UP501, and they were as short as possible to permit the UP501 to mount directly beneath the XBEE/Simple board. I am reasonably sure the power/ground were not picking up noise, especially since the smaller value caps were not helping the situation.

During indoor testing this morning with the unit placed by a window, my second prototype (in the pics) achieved lock in 60 seconds flat from a cold start. It sees 10 satellites from that window. This is fairly impressive performance compared to what my first prototype was doing. I recycled the UP501 and 900HP from the first prototype, so the only major difference here is the layout and the dual regulators.

Again out of curiosity, how long does it take your tracker to achieve lock from cold start? I wonder how long it takes for a warm start. I did not build-in a provision to test this, but I am very happy with 60 seconds. That's way faster than any GPS unit I've ever used before. I am very impressed with the UP501. It is an amazing little piece of technology.

 

[Derek]

I had problems with my droids xbee adapter too. the gps would never lock when using their regulator. I measured the 3.3v rail at ~2.8v when the gps was connected. I solved the problem by connecting the gps to the battery. Works fine.

I don't believe the regulator on my droids board is capable of sourcing 400ma.

 

[mikec]

Antenna mass is not a significant issue in my case....
Again out of curiosity, how long does it take your tracker to achieve lock from cold start?

I'm not so much worried about the antenna mass as the fact that the mass tends to pull the XBee out of its socket, or applies a bending stress to it. I haven't seen much range impact from using a wire antenna at ranges of a mile or so, but I certainly haven't done much flight testing.

Cold-start times appear to vary a lot with satellite geometry, at least for the Venus. I've gotten lock in as fast as 30 seconds with the Venus (newest version). The MT3329 is usually no more than a minute. My concern is how well the MT3329 handles flight dynamics; I've flown it once and had it completely lose lock, but that was with the DIYDrones module, not the UP501, which seems to have a better RF design.

 

[Derek]

I received the pcbs last night and got to assemble one at lunch today. The good news is

THEY WORK!

Yeah! :clap:

The silkscreen is mostly unusable, but the important parts are readable (the +/- battery terminal labels). I can live with that. It took about 30 minutes to assemble, and I made tests at different points in the assembly to test it. The low voltage cutoff works as designed and the 400ma supply seems to have more than enough oomph.

I'll attach a pic of the bare boards and my assembled one tonight when I get a chance.

 

[bigredbee]

If you want to send APRS instead of NMEA, I think you'll have to abandon the xbee radio. It's using FHSS algorithms on 900 Mhz, and APRS wants a single frequency. Unless you're planning on re-writing the low level firmware on the module? But I think that the "aux processor" variant just populates a microcontroller on the top side of the shield, is that correct? if so, then not really an different than any external processor that lives on the "motherboard".

AND, the XBEE radios at $40 or so are expensive compared to just a few dollars for an ADF7012 which is what's inside the Xbee IIRC.

Greg

 

[Derek]

Here it is:



On top is the finished transmitter, middle is the top of the pcb and the bottom is the bottom of the pcb.

 

[AZ_Ron]

Very nice Derek... Please keep us posted on availability of the pcb, and maybe a parts list? Seems like a fairly easy project for anyone with decent soldering skills!

R

 

[sti_ffy]

If you want to send APRS instead of NMEA, I think you'll have to abandon the xbee radio. It's using FHSS algorithms on 900 Mhz, and APRS wants a single frequency. Unless you're planning on re-writing the low level firmware on the module? But I think that the "aux processor" variant just populates a microcontroller on the top side of the shield, is that correct? if so, then not really an different than any external processor that lives on the "motherboard".

The APRS protocol using X.25 UI frames was what I meant. This is run over networks routinely, and digimesh is just another network. From what I've read, the aux processor on the XBEE radio sits between the transceiver and the uart, and was intended to act as a protocol encoder/decoder. It seems that would be ideal for translating NMEA to/from APRS.

I wrote to Digi asking how one would go about obtaining a 900HP DM radio with an aux processor. They wrote back saying someone would get in touch with me, but this never happened.

 

[dickmoran]

Looks good. Can't wait till it becomes available. Let us know.


Thanks

Dick