New tracker range test result

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
You could use the same functionality to keep a directional antenna pointed at the bird. That would improve the S/N ratio during high flights. Might be a bit tricky under boost!

I'd suggest a patch antenna as opposed to a Yagi but once the rocket is really moving out, the GPS is going to lock out and there is nothing one can do about it with COTS products. Once the speed drops, the receiver can reacquire a signal.
High G's can momentarily cause loss of GPS lock but the chipset can reacquire it very quickly. Go too fast >1200mph/1000knots and the thing locks out.

Very impressive flights.

In some places it would be nice to be able to pipe the lat/long to a map for the visual "types" but it certainly looks to perform well to find ones rocket. Out west there's not much to see on a map but in other places it's nice to have a picture of the likely recovery area so one can plan the recovery route based on nearby roads and obstacles. Yeah one can manually input a last lat/long into a map but I'm lazy and like automatic better.
Plus I get a kick out of seeing the rocket icon jump a bit when I reacquire valid signal of the final resting place. I think Adrian will become rather popular amongst the crowd with this device.

Kurt
 
Thanks for the explanation Kevin. Looking really great. Excited that real world tests have been, that always leads to a better product. Good luck to you and Adrian at getting them done and for sale.

While I do see the advantage of a less expensive base station without the GPS and using the phone's GPS instead, don't let the delay you from getting 1.0 out the door. Lots of eager folks out here wanting to be able integrate the tracker into their builds and are ready to plonk down some cash. The best part is that no loss if you bring out a less expensive base station since of course the current one then becomes a full fledged tracker.


Tony
 
In some places it would be nice to be able to pipe the lat/long to a map for the visual "types" but it certainly looks to perform well to find ones rocket.

my first test will be to see if I can use Apple maps and dropped pins but will also look into googlemaps integration even if it is via a 'share' button that sends the location to googlemaps (so not necessarily a live tracking but you could at least get a pin and satellite / map view).
 
While I do see the advantage of a less expensive base station without the GPS and using the phone's GPS instead, don't let the delay you from getting 1.0 out the door. Lots of eager folks out here wanting to be able integrate the tracker into their builds and are ready to plonk down some cash. The best part is that no loss if you bring out a less expensive base station since of course the current one then becomes a full fledged tracker.

I'm pretty sure we would not delay for a no GPS design since as you note, any sold now as ground stations could still be used as trackers - which is a very nice feature...!
 
And yes also, basically you could keep anything (antenna, camera, etc) pointed at the rocket - and with a good zoom on the camera would be able to capture things you wouldn't normally see...
I would be interested in doing the mechanical work for this.

Sent from my HTC6535LVW using Rocketry Forum mobile app
 
End of February maybe [emoji848]


Sent from my iPad using Rocketry Forum
 
2018-02-10 update ...... If you are reading this thread at a later date, there have likely been updates to the status below... :smile:

So I'm in the Phoenix area and we flew five flights successfully with the units at the January TRAPHX launch. I'll be going to the February launch and I'm sure we will get some more flights in there too. The iOS app is working but had the glitches mentioned earlier in this thread (still worked fine but one loss of BLE pairing issue was annoying since I didn't go on that rocket retrieval where I could have maybe resolved it).

But one remaining issue we are working with is the over the air firmware update...

For the past few months, I have done all the development using that to update the firmware (as a way to validate the robustness). I would build the BLE project, embed it in the iPhone project and then the iPhone would detect a difference in the firmware and command the device into 'update mode' (where the BLE device reboots into a special firmware update mode and that's where the BLE over the air update protocol exists).

And over the past few months I have had ~3-4 times (out of 100+) where the device reboots, but reboots back into the normal application mode (instead of the OTA update mode). Currently the phone then detects that it still has out of date firmware and commands it to reboot again and it gets in a cycle of reboot, detect firmware out of date, command reboot to OTA mode.... repeat.... My prior attempts to use the debugger to figure out what is going on resulted in the device getting reprogrammed - and then it works fine again... [and the reboot to OTA is using standard code provided by the maker of the chip.]

So another unit did it yesterday... so my goal for today is to first get the phone to detect that it is now in a loop that it is likely not going to succeed at, and just switch to just using the firmware as is. This would at least prevent a unit from suddenly becoming unusable because the phone *insisted* on a later version of firmware and the unit was unable to do the update to get there. The base protocol is stable enough now that it would still support all standard tracking and configuration changes (frequency, rocket name, etc) and . It might however not be able then to use newer features in the updated phone app (if they used any newer 'messages' over the BLE)... Some customers would be maybe OK with that as they just want a tracker (and they really wanted it last month... ;-) but others would be upset by their lack of ability to get the possible upgrades. Most other products have no "in the field firmware update" capability so this is not as bad as it might sound - but we really want to be able to improve and proliferate new changes... and do it automatically and without expecting some customer returns for firmware updates to get it going again... Now, the radio chip still can get OTA updates as that protocol is implemented in the normal app mode (so Adrian could still improve the coordination, found rocket etc and those updates could be available to the phone - as long as they didn't require a new BLE 'message').

So, I'm going to get this unit working as is with the out of date firmware while we work on figuring out the underlying issue. I'm also going to implement a simple protocol that is a passthrough between the phone and radio chip - so then most updates would still work because the radio chip can still be updated and the phone can be updated.... That might be enough to make us feel comfortable about starting the release because we could at least guarantee future updates would all be available to anyone - and maybe no BLE update would ever be needed.

Thanks for your patience! ... And I understand the impatience as well! :smile:

/kjs
 
Thanks for the hard work and update! I’ll check back in about....2 hours. [emoji6]


Sent from my iPhone using Rocketry Forum
 
Sounds like you could make the auto-updates an option and ship v1.0...? ;)

Code:
if (updateDetected) {
    UIAlertView(“Do you want to update to v1.0.1?”)... {
        if (true) {
            startUpdateMode()
        }
        else {
            continueNormalMode()
        }
    }
}

I personally prefer the option of updates when I’m dealing with flight hardware. I may be wildly out of the norm, but I always test my electronics after I do any updates to make sure they’re working as I need them to (e.g. altimeter charge test in a vacuum chamber or GPS test driving around). It’d be tough (or at least frustrating & time consuming) to do any regression testing if the unit decided to do a mandatory update in the field.
 
The more options = The more time to develop. Be patient.

Otherwise............The "less understanding" will be screaming and yellling bloody murder if something doesn't work. If one needs a tracker that works below 10k "RIGHT NOW", there are plenty of options out there already.
Plus the mesh search option isn't going to work until this device permeates the community so much that there's more than one flying at the same time. Isolated club launch? At least you'll probably be the only one with
this device unless it's a really large club that is well attended every time with many folks that bought the tracker. I'd say chill until they're confident to release/sell it. A bad first showing isn't going to do it any good.

Kurt
 
Sounds like you could make the auto-updates an option and ship v1.0...? ;)

Code:
if (updateDetected) {
    UIAlertView(“Do you want to update to v1.0.1?”)... {
        if (true) {
            startUpdateMode()
        }
        else {
            continueNormalMode()
        }
    }
}

I personally prefer the option of updates when I’m dealing with flight hardware. I may be wildly out of the norm, but I always test my electronics after I do any updates to make sure they’re working as I need them to (e.g. altimeter charge test in a vacuum chamber or GPS test driving around). It’d be tough (or at least frustrating & time consuming) to do any regression testing if the unit decided to do a mandatory update in the field.

Actually if you don't update the phone app, it will stay where it is. but when you update the phone app, it is bundled with the firmware that it was developed with so we *really* want to update the firmware then or we risk forward/backward compatibility issues.... make sense?
 
Actually if you don't update the phone app, it will stay where it is. but when you update the phone app, it is bundled with the firmware that it was developed with so we *really* want to update the firmware then or we risk forward/backward compatibility issues.... make sense?

As an example for mismatched software version, years ago, I saw two different L3 attempts by the same flier that both resulted in a main at apogee flight. Turned out that G-Wiz changed how it encoded main altitude in its configuration settings. This flier had mismatched software versions, which wasn't caught by the software. The PC software transmitted the setting it in 10s of feet, the G-Wiz interpreted it as 100s of feet (IIRC).

A tight coupling between FW and app version could get tricky if people want to use it with different devices (e.g. shared ground station), especially when the Android version gets released too. People might realize this to late (e.g. no data available on the launch site) or when other issues prevent the app from being upgraded (e.g. unsupported OS versions, years from now). Can the FW be downgraded too, if necessary? How about communicating the protocol version and trying to keep the core of the protocol stable? Based on that, various fallback options or upgrade paths are possible.

Reinhard
 
Actually if you don't update the phone app, it will stay where it is. but when you update the phone app, it is bundled with the firmware that it was developed with so we *really* want to update the firmware then or we risk forward/backward compatibility issues.... make sense?

Ah....this is how AltimeterThree works, too - bundling the device firmware with a new app version and then pushing it to the device. I’m sure John Beans will gladly commiserate with you on the vagaries of how Apple’s Bluetooth stuff works.
 
I'm getting ready to place a production order for 500 units, ...Aaaaand the LoRa radio modules are out of stock at Digikey. ...And Mouser. And Av-net. And Newark. And Future. And Arrow. Somebody else must really like these new LoRa modules, too. So unless I can find some other source (I have asked my assembly house to look around, too) the next production run can't get started until a distributor gets in a new shipment in :y: mid-June.

I have an email folder of people who have requested notification when we're ready to accept orders from our first mini-run of hardware that got done in December. I'll need to count to see if we have enough to cover 1 pair for each of those people plus sufficient units for Kevin and me to complete the firmware development.
 
...a distributor gets in a new shipment in :y: mid-June.

NCm7TIS.gif
 
On the plus side maybe it will give you more time to get the Android piece functional? :grin:
 
Well it looks like I probably don't need to buy a used iPhone before Airfest, so that's more motor budget. Gotta' stay positive!
 
Wow, that is a major bummer to lots of folks, of course including you and Kevin. That's a crazy amount of time to be backordered, you'd think the demand would push up production. Hopefully those who get units will be able to provide good feedback in the meantime.

Good luck with an alternative source,


Tony
 
I’ve been poised to buy one and have checked on the Featherweight site pretty obsessively. So I was pretty bummed to see this, this made me curious about the company that makes them (assuming I’m correct that it’s Semtech) so I did a little digging. Apparently these components are very useful for locating lost Alzheimer’s patients, that sort of put it in perspective for me. Still I’m very anxious to get one, I’ve got two rockets in desperate need! Also it seems Semtech (SMTC) might be a hot stock! Hang in there Featherweight it’ll be great!
 
Thanks for the support, everyone. My apologies for not stockpiling the parts while we finished up the first software release. Since the first release has seemed imminent for a while now, I didn't think to watch for parts going out of stock in the meantime. Sometimes parts unexpectedly show up at a distributor, so I'll keep checking, and we'll do the next run as soon as possible, even if it's a smaller run. In the meantime, the first production batch is large enough that we can do multi-user benchtop and flight testing, since some of the first customers are regular flyers with the Az and CO clubs where Kevin and I fly.

this made me curious about the company that makes them (assuming I’m correct that it’s Semtech)

Yes, the radio chip is from Semtech, who has the patents for LoRa. The Featherweight Tracker is built around an FCC-certified module that incorporates the Semtech chip and a microcontroller.
 
Back
Top