Smartphone GPS Tracker Version 1.0

[mikec]

It's that extra half-volt with the fully charged lipo that I believe should be avoided.

Derek is using a low-dropout linear voltage regulator to derive the radio power. It will work over the full range of lipo output.

 

[Derek]

My only suggestion would be to try different mapping sw. Google earth perhaps? If the gps tools indicate you are getting a fix, then the hardware is ok.

Sorry.

I have bread boarded my new equipment and I am getting a signal into my netbook but my GPS SW is not seeing it. I thought that the last time I lashed this stuff together I was able to get the GPS SW to lock on but not this time. Anyway I have some GPS diagnostic SW which is seeing the XBee received signal and is decoding it and showing Lat and Lon along with all the other bits in the stream like what sats it is seeing etc. So what I will do now is plug my Earthmate GPS receiver in one usb port so my GPS SW will be operating and plug my XBee usb device in another usb port. Fire up the GPS SW and the GPS Diag sw. Read the last Lat/Lon from the XBee and put that into the GPS SW manually as my destination. That should work for now. I would love to purchase a TX PCB if you get it built. I did pick up 2 of the Droids simple boards and some other fun stuff before I read your last post. Anyway I need more stuff on my bench that I won't use.
Thanks,
Dick

 

[sti_ffy]

Derek is using a low-dropout linear voltage regulator to derive the radio power. It will work over the full range of lipo output.

Thanks. Derek didn't mention a regulator in his reply to Dick Moran. I've been looking at readily available 3.3V regulator boards - but they all have input requirements that don't suit this application. Most are intended for 5V input and have a lower limit of 4.6V or so (higher than that of a fully charged 1S lipo).

 

[Derek]

Thanks. Derek didn't mention a regulator in his reply to Dick Moran. I've been looking at readily available 3.3V regulator boards - but they all have input requirements that don't suit this application. Most are intended for 5V input and have a lower limit of 4.6V or so (higher than that of a fully charged 1S lipo).

here is the regulator I'm using:

https://www.ti.com/product/tps73632

 

[dickmoran]

Brought all my stuff to work today and powered everything up. Had my cousin play with the Delorme GPS SW and he was able to set the config to make it work again. Now for some testing. I left my lap top in my cousin’s office with the GPS Mapping SW running. I put my ac powered adj power supply on a cart along with a small APC UPS and attached my XBee Pro 900mhz 250mw TX/RX along with the UP501 GPS receiver. I then took the whole thing out side for a walk around the building. The Mapping SW showed my entire route around the building and next door without a dropout. This was with the receiver in an outside walled office and the tx on a cart. The farthest was over 600' through the building to the far most parking lot. I can’t wait to try this in a open field. We decided that when we go to the Hi Power field we will put the USB adapter board for the XBee along with the XBpro and the rubber ducky antenna on the top of a extendable painters pole and attach a USB extension cable to this stuff and plug it into the net book. That way the electronics will be high enough to see over some of the nooks and crannies in the fields we fly in.
There are still some lingering questions about power. We have seen all the postings but we have 80 yrs of combined experience in electronics and have been burnt by spec sheets that lie. We will do some real world testing on our end and see what we come up with. Mikec said that "Derek is using a low-dropout linear voltage regulator to derive the radio power. It will work over the full range of lipo output." I missed that and would like a little more info about the regulator if possible.
We appreciate all the time and effort done by Derek to bring this project to life. Keep it up!!
Dick
NAR 6306 L1
TRI 14074 L1
MDRA 106

 

[Derek]

Dick,

See my post above yours about the regulator. You didn't miss an earlier post from me about what I used for a regulator. Mike has reviewed the schematics which is how he knew that.

Derek

edit:

data sheets don't lie - they have erratas.

 

[mikec]

Mike has reviewed the schematics which is how he knew that.

That and the fact that it's almost impossible to build a battery-powered unit without using a regulator given today's voltage and voltage tolerance requirements.

 

[dickmoran]

I was typing my message while others were answering my questions.... Thanks for the update!!

As far as data sheets go we use data sheets daily to determine if a product is applicable to what we need done. It is not unusual to find major manufactures stating that their equipment can do X for Y without Z. We ask for eval units and we see if it really can or are we getting the marketing smoke screen data sheet. We are not in the component business anymore and for the last 15 yrs or so are seeing completed systems and some cannot stand up to close scrutiny. Every line of work see their share of data sheets and some companies are better than others.
Sorry: Off Topic...

Thanks again for the info and I can't wait to get out to the field and fly!!!


Dick

 

[Derek]

The first bare pcbs for the transmitter have been ordered!

woohoo!

 

[sti_ffy]

I noticed in the "specs" page on their website and in the user guide that Digi makes a version of the XBEE PRO 900HP module with an auxiliary processor that intercepts the UART connections. This is intended to permit customized data manipulation, and would be perfect for translating the NMEA strings from the GPS unit into APRS. The trouble is, they don't list the part number for this optional processor variant anywhere. I have no idea how to order one. The "normal" module seems to have a spot on the topside for a chip - I assume that's where the aux processor goes.

They also make an XTEND module which is very similar to the 900HP module except that it is packaged much more robustly, accepts a wide-range input voltage, produces 1W output and tolerates horrendous temperature extremes. It costs $179, but for those with a large and expensive rocket the rugged nature of this module might be preferable.

 

[sti_ffy]

here is the regulator I'm using:

https://www.ti.com/product/tps73632

You chose 3.2V output (over 3.3) to improve the DO margin? It looks like you could go as low as 3.0V without any range degredation if the Digi specs are accurate.

 

[dickmoran]

I will be waiting. Do you have any idea of cost and lead time? Will you sell the extra bits required such as caps and regulators etc? I am guessing that the board will have holes for mounting to the av bay?
Just got word that with 90% chance of freezing rain here in Maryland there will be no launch tomorrow.
More time to get it right...

Thanks,

Dick

 

[Derek]

You chose 3.2V output (over 3.3) to improve the DO margin? It looks like you could go as low as 3.0V without any range degredation if the Digi specs are accurate.

yep.

you could sub in a 3.0v part, but the regulator has a tolerance on the output voltage so it could very well fall below 3.0v. Since I have know idea what the radios would do at voltages < 3.0v, I chose to play it safe. They are vague with a statement about degraded performance, or something like that.

however with the supervisor I have on board, as the battery drops below ~3.2v, the 3.2v rail falls as well. once the battery hits ~3.08v, it shuts the regulator off. so in theory I'm using almost the entire safe voltage range of the lipo and preventing over discharging it.

 

[Derek]

I will be waiting. Do you have any idea of cost and lead time?

nope. not yet. lead time on the pcbs are 2 -3 weeks. I only ordered 3, and they are spoken for.

Will you sell the extra bits required such as caps and regulators etc?

maybe. all the parts are readily available from places like digikey and mouser.

I am guessing that the board will have holes for mounting to the av bay?

yep, it has 4 #2 mounting holes in the corners. these actually caused we the biggest issues in the design.

 

[Derek]

The transmitter looks something like this:

 

[dickmoran]

I would like to get in on buy #1, is it too late to bump the qty up 1 or 2? I will pay for the phone call. I'll give you my CC# or PayPal info............
I have been involved in the pcb process in the past and would accept the liability of a few cuts etc to make the first build work if not perfect....

DIck

 

[dickmoran]

Just an update on my XBee hardware status. If you remember I made the mistake of reversing the power leads on the rocket side XBee and GPS module. I assumed that I had fried both parts. After getting my new XBee 250mw modules and my new GPS chip I hooked that stuff up and it worked. While playing today I decided to check out my old XBee 100mw modules. At first I swapped out 1 250mw with a 100mw and nothing. When I swapped out both 250mw units with the 100mw units it worked! Sadly when I tried my original UP501 module there was no output from it. Anyway that dropped my loss to $31 plus shipping and I have 2 new 250mw units. Need to look at the module config files to see why they dont work between the old and new. Not a big problem but it will take some time along with my cousin who just received his XBee stuff and is already at the 10,000 ft level in knowledge.

Dick

 

[sti_ffy]

We've been doing some testing with Digi XBee-PRO S3B 900HP modules, and there are some details about how these radios operate to which everyone should be made aware. I hope I am not about to embark on one of those "duh - shutup we know that!" moments.

Out-of-the-box the radios transmit in transparent mode, and only via broadcasts. This is why it is so easy to get a pair of them to cooperate with one another, but it also means that every receiver will see every transmitter's messages. If two or more people at your field are flying GPS units using these radios, and no measures have been taken to prevent them behaving as one big party line, then everyone is going to be unhappy. Each person will be receiving NMEA strings from all the rockets. Which one is yours? If you are using GPS software, it is going to be confused since your position appears to be hopping all over the map.

There are 2 ways to address this:

1) Change the pre-amble or network ID of your two units to cause them to ignore all radios not on their net (andd vice-versa).
2) Change the destination address in each of your radios to point to your other radio's source address (they send only to each other).

I think #2 is by far the preferred solution. Once you've programmed your radios to transmit unicast messages rather than broadcast messages, the "digimesh" protocol becomes effective. This causes the modules to behave much more intelligently, with routing tables, acks, repeating, etc. All the other radios on the field which have the same pre-amble and network ID become potential repeaters. If the signal strength between your rocket and base station becomes weak, but there is another rocket in the air or on the ground between the two, that rocket can repeat the signal and you will get your data. This repeated data is NOT output on the UART of the repeating modules, it is only repeated over the air - so there is no confusion of the signals at the receiver as there will be if everyone is broadcasting. This all happens automatically so long as all the radios are configured to send unicast transmissions and are on the same net (and using digimesh - some of the earlier XBee radios do not support this protocol).

This lends itself to some cool possibilities, like placing modules on helium balloons near the periphery of the field and extending the range. Rockets on the ground will not have a very long range, but a module on a balloon would easily connect to it and relay the data back to your ground station.

Keep in mind that it only takes one person NOT configuring their radios for unicast to mess up everyone else's tracking, so please look into using the X-CTU software (available through Digi) to configure your boards to send only to each other rather than to broadcast. If anyone needs help locating the X-CTU software or using it to change the configuration of their radios, I'd be happy to help in any way I can.

Although the digimesh modules use very sophisticated techniques to minimize unncessesary repeating the available bandwidth is limited, so there may potentially be trouble if lots of trackers are transmitting their positions. Perhaps the worst that would happen in this situation is delays - you just won't see the NMEA at 1Hz. I'd like for this to become a problem (that many radios tracking at once).

The 250mw Digimesh module number for use in the US (depending on desired antenna type) is:

XBP9B-DMWT-002 = Wire Antenna attached to module
XBP9B-DMST-002 = RPSMA Antenna connector
XBP9B-DMUT-002 = U.FL Antenna connector

The RPSMA is the more available antenna type (as opposed to U.FL)

Thanks, Derek, for one of the most interesting threads I've participated in some time. This is very cool stuff.

 

[Derek]

Thanks for your input!

I have only glossed over the configuration of the xbee radios, but I have been wondering about configuring them correctly. This is something I need to study more so I understand how everything works.

I know digi has a bunch of different part numbers for what appears to be the same device, but with subtle differences. for example, there are 2 versions of the xbee pros xsc s3b module with the rp-sma connector - one has a air data rate of 10 kbps and the other has an air data rate of 200 kbps. I bought the 10 kbbs versions as range is more important to me, but either module can be changed to the other by loading the other firmware. digi is pretty good about providing firmware for all the radios. I believe this is also true for digimesh vs. point to point/multipoint firmware.

one other point brought up by mikec is the older, non-s3b versions can't be configured over the air, whereas I'm pretty sure you can with the newer s3b versions. This means that you if you use these modules and want to solder them to a board, you need to configure them before you solder them, or you'll be removing them and doing it again.

thanks again for pointing this out. I'll be sure to ask if I run into any issues trying to figure this out.

 

[sti_ffy]

The 10kbs version bears the same part numbers except the dash number is -001 (instead of -002).

The differences in the -001 and -002 variants are:

-001 = -110dbm rcvr sensitivity but NO DIGIMESH
-002 = -101dbm rcvr sensitivity with DIGIMESH

Both can repeat unicast transmissions not destined for themselves.

I am not sure if they will play together or not (-001 repeat traffic for -002 and vice-versa). This is not something I have tested yet.

 

[mikec]

This causes the modules to behave much more intelligently, with routing tables, acks, repeating, etc.

I've only used the old-style Pro 900 XSC modules that didn't have any of this stuff, but most users of XBees in drones, robots, and other mobile apps say that the Digimesh stuff is painful to set up and debug and doesn't really provide a lot of benefit in real-world situations. I just set my destination address and hopping channel to some random, hopefully unique value, which is more like your option 1. FWIW.

 

[Derek]

I've started looking into this and I see that there are two different firmware versions for the s3b hardware: xsc and 900hp (digimesh?). I bought modules with xsc fw. The manual leads you to believe 900hp is newer/better/faster and xsc has been deprecated.

I'm pretty sure you can load any of the fws on a given module. I need to rry this out tonight.

They documentation about this isn't super clear and them don't make it easy. Grrrrr.

 

[Derek]

...say that the Digimesh stuff is painful to set up and debug and doesn't really provide a lot of benefit in real-world situations.

that was my experience with using the zigbee modules. way too complicated to just send data between two modules.

 

[sti_ffy]

most users of XBees in drones, robots, and other mobile apps say that the Digimesh stuff is painful to set up and debug and doesn't really provide a lot of benefit in real-world situations.

This has not been my experience so far. We used 4 modules new out of the box. One was connected to the GPS module. The second was connected to a PC USB port with an app (either Street Atlas or GPS Diagnostic test utility) seeing NMEA sentences from the GPS module. I fired up a third XBEE module on another PC USB port, and I saw the same NMEA sentences from the first transmitter. This is because the first module is transmitting broadcasts.

So, I edited the "destination address high" and "destination address low" values in module 1 to reflect the "Serial number high" and "Serial number low" values from module 2 and vice versa. I edited the "destination address high" and "destination address low" values in module 3 to reflect the "Serial number high" and "Serial number low" values from module 4 and vice versa.

The only fields I edited or changed in ALL FOUR modules was their "destination high address" and "destination low address". Everyone should be doing this anyway - it makes no sense to be broadcasting.

Once these values were edited, we verified that the second module still sees the NMEA sentences but now the third module no longer sees any data from the first module.

Now here is where it gets interesting. We placed module #1 (the NMEA source) in one corner office of the building. The second (and third) modules were right next to one another in office #2 halfway down one side of the building from that corner. The second module was receiving NMEA sentences and the third was powered off. We power on the third module, and its RSSI indicator remains OFF. It is now basically passive - it isn't actively participating in any of the traffic that is being passed between the other two (which consist of NMEA sentences from module 1 and ACKs from module 2.

Now we move module #2 down the hall, around the corner and down to the far end of that hall. It is now separated diagonally across the building from module #1 (the NMEA source). It loses the signal, and the RSSI LED lights up on module #3 in office #2. The signal is restored to the second module - the third module is now acting as a repeater, permitting the first module to reach the second. The power and RSSI LEDs on the third module blink almost imperceptibly each time it transmits a repeat, but nothing comes out the UART into this PC. If I disconnect this third module from power, the second module loses the signal from the first.

So we have demonstrated that the ONLY thing that needs to change is the destination address. No other tweaks or twiddles are needed. It just works.

We plan to do some more long-range testing outdoors to include 3 hops (all four modules). I will let you know how this goes...

 

[dickmoran]

When I read this my eyes start to glaze over reading it BUT I was there during this and it was very easy to do. If we don't do something to the default settings it may make the operation unworkable if there are any other fliers on the field using the same hardware. I am sure sti_ffy will squeeze out every last mw of performance from these things and come up with a programming process a baby could follow. He is like a pit bull when it comes to stuff like this.
Stay tuned for more knowledge transfer...

Dick

 

[Derek]

thanks for the info, sti.

I've been reading the xsc fw docs some more, and it seems like xsc lacks the api which means that you can't change the modules without removing them from the boards. I think that is a bad idea so I'm going to focus on the 900hp fw now. I hope I can convert my xsc modules to 900hp...

 

[Derek]

well, I'm slowly learning more about these xbee modules. I bought the xbp9b-xcst-001 modules. this was probably a mistake. I think I should have bought the XBP9B-DPST-00x modules (900hp point2multipoint version).

it turns out not all xcst modules can run the 900hp fw, but all digimesh/p2mp modules can run either fw. you need rev h or later xcst modules to run both firmwares. mine are rev e.

before I figured this out, I tried loading the p2mp firmware on one of my radios and I thought I bricked it. It must have been stuck in a bootloader and I was able to reload the xsc formware on it and fix it. yeah for digi!

I also think I've figured out the difference between the digimesh and point2multipont modules and firmware, too - the air data rate. digimesh uses a 200 kbps air rate, point2multipoint is 10 kbps. that looks to be the only differnce I can find between the two. you should get better range at 10 kbps, so that is what I plan on using.

so, it seems that buying either the digimesh or point2multipoint radios is the safer bet. I'm pretty sure we will want to use the 900hp firmware because it allows you to make config changes over the air. this will become important if you solder the module down instead of using sockets. the sockets are pretty flaky, so I suggest ditching them and soldeing the radios right to the board. that's what I'm doing.

Derek

 

[Derek]

This has not been my experience so far.

I think mike is using the older xsc firmware modules.

what are the complete part numbers for all of your xbee radios? it is printed on the sticker on the bottom of the module. it should start with something like xbp9b-xxxx-xxx.

 

[Derek]

sti,

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'm curious as to how your rssi leds works if you do infact have the newest radios.

great testing, btw. I had to read it a couple of times before it clicked, but now I get what you are saying. very nice!

 

[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'm curious as to how your rssi leds works if you do infact have the newest radios.

Maybe this has more to do with which USB module you use? I don't have an accurate schematic of mine - which is a Sainsmart unit.

https://www.sainsmart.com/new-sainsmart-xbee-usb-adapter-explore-with-high-quality-usb-cabel-for-zigbee.html?___store=en&___store=en

I didn't really understand why the RSSI LED did not register anything until the module "joined the conversation". It was obviously receiving the data before - just ignoring it.

With regard to the difference between P2MP and MESH, one huge difference is this (page 33 of the user guide - under the header "Point to Point/Multipoint"):

This delivery mode does not use a network header, only the MAC header. All messages are always sent directly to the
destination. There is no repeating of the packet by other nodes.
​

Mesh has the advantage of all nodes acting as repeaters when necessary in order to get a transmission through. I think this is an exciting aspect for clubs to look into. Standardize on a preamble/LAN address and scatter 3 or 4 radios on sticks or under balloons on the outskirts of the field and everybody can track their rockets successfully without any high-gain antennae. At $40 a radio, this may have potential.

I posted the radio part numbers previously - Dick Moran and I have the RPSMA connectored models:

XBP9B-DMST-002

Digi promised to get back to me about the "aux processor" variant. I'd like to get my radio sending APRS instead of NMEA.

- Jim