Xrw Mode

[richo]

This is a totally untested firmware patch (I hope to test it this weekend at the DZ) but making a PR now to solicit feedback.

The intent is to play a sound 45 seconds after exit, and then a further 60 seconds after that to give some indication of when the build and scoring windows have elapsed for the new XRW league.

None of this functionality is enabled unless you set values for the XRW settings in config, so even if it's horribly broken it should not break anything.

Thanks in advance for reviewing!

[willglynn]

Hello! 👋

I haven't looked through the PR, but I would like to point out a CI feature: the Travis build output links to a build report which includes the ability to download your build artifacts. If you're testing a build this weekend, consider using the binary from this CI build instead of from your local machine :-)

[richo]

Hey!

That's awesome, thanks. I'm currently running into a hilarious problem where I can't get VLC to emit wav files in the format flysight wants, so instead of a soothing "build window" I get pterodactyls screaming in my ear. Is there a recommended way to format correctly?

This also turned up a misfeature where the audio files are hardcoded, I will amend that at some point.

Is the rationale behind using the Travis artifacts just to make sure I haven't done something ridiculous with my local environment?

thanks for the quick reply!

[willglynn]

It's not a requirement to use the CI output, and I'd be surprised if it were materially different than a local build. Having said that, if somehow this tree managed to work for your local build but not in CI, that'd be a problem worth finding.

I don't see how that could happen here, but still, it's a way you could test this PR as it exists in GitHub as opposed to how it exists on your local machine :-)

According to file, audio is all "RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit, mono 7812 Hz". There's an Audacity project which appears to have that rate setting, and this untested ffmpeg snippet appears to produce a similar format:

$ ffmpeg -i original/build.wav -ar 7812 -ac 1 -c:a pcm_u8 -y audio/build.wav
$ ffmpeg -i original/score.wav -ar 7812 -ac 1 -c:a pcm_u8 -y audio/score.wav

[richo]

Thankyou! I was using file output to drive VLC although I'm on OSX and wound up hacking at it's plist file because the UI doesn't actually change all the options it claims to.

Worst case, the shrieking will definitely get the point across that I've blown through a window :) I'll try your ffmpeg snippit, in retrospect that's probably where I should have started. Thanks again for your help! If we end up getting two days of jumping this weekend I'll test travis output the second time, I anticipate making some changes during the day the first day, since part of this patch attempts to detect the exit, and the heuristic I'm using is.. really naive at best.

cheers

richo

[richo]

Sorry one last thing, beyond trying this in the air and confirming it works, and fixing up that hardcoded audio value is there anything else you would like me to do to get this merged? I realised that the docs are a little lacking, I can easily add something to the default config and also write something in the wiki.

[willglynn]

I don't speak for @crwper, and he's the one with merge powers. Having said that, I'll provide my assessment.

The runtime impact for anyone with out these new settings is exactly this snippet of code, executed each pass through UBX_ReceiveMessage():

    if (UBX_xrw_build == 0 && UBX_xrw_score == 0) {
3af6:	a0 91 3f 07 	lds	r26, 0x073F
3afa:	b0 91 40 07 	lds	r27, 0x0740
3afe:	89 2b       	or	r24, r25
3b00:	8a 2b       	or	r24, r26
3b02:	8b 2b       	or	r24, r27
3b04:	69 f4       	brne	.+26     	; 0x3b20 <UBX_ReceiveMessage+0x2ac>

This feature also statically consumes some memory resources. Using the figures from the last release (v20170405) as a baseline:

Program:   40442 bytes (61.7% Full)
(.text + .data + .bootloader)

Data:       3184 bytes (77.7% Full)
(.data + .bss + .noinit)

…we see that build 141 (v20170405-11-gd6be560) weighs in at:

Program:   41052 bytes (62.6% Full)
(.text + .data + .bootloader)

Data:       3180 bytes (77.6% Full)
(.data + .bss + .noinit)

So we're talking about an optional feature costing 610 bytes of program space, -4 bytes of RAM (?), and 6 instructions for non-users. Assuming it does what you want it to do and that it doesn't conflict with any features @crwper has in mind, I don't see any blockers 😄

[crwper]

:-) You guys are way ahead of me here. To add to the discussion about audio, we have this video tutorial showing how to produce the files using Audacity:

https://www.youtube.com/watch?v=KNmeb2j3HjE

Specs for the file are as @willglynn has indicated.

As far as merging, I'd like to see the feature tested first, but will also review the code myself to make sure there are no lingering issues.

The biggest issue we face with the firmware these days is RAM use. Even though the latest release shows only 77.6% usage, common wisdom seems to be to leave the top 25% for the stack. We've got lots of program space to spare, so from a resource perspective I don't see any issues.

[richo]

Lovely, thankyou!

I will test it in the air this weekend and report back. I just added support for specifying that files to play at each of the windows, but if we're trying to conserve space I can back that out (although it only consumes 18 extra bytes).

The ffmpeg advice worked great, I will probably add it to the wiki.

[crwper]

@richo I locked down edits to the wiki a while back when we got hit hard by spammers, but will take a closer look at permissions this weekend. I'd love to have your contributions in there as well.

[richo]

Update: I jumped it over the weekend, and my exit detection heuristic is.. awful.

I'm going to spend some time futzing with it during the week, but if anyone has ideas, or if something like this already exists then please feel free to point me at it :)

[willglynn]

@richo Three thoughts.

First, from personal experience, I know that the L&B Altitrack samples barometric pressure at 4 Hz. At its most sensitive ("student"/hop and pop mode), it decides you've exited once 9 samples all indicate descent. I've had a few false positives (descending in the plane) and exactly one false negative (a CRW jump when the plane may not have been level at exit) but this has been pretty robust.

Second, bad news: Altitrack is driven by a pressure sensor rather than satellite signals, and I would expect satellite data to have unusual artifacts.

Third, good news: Flysight records position data whenever it's on, so you have the information needed to proceed. It's pretty easy to detect exits when you can see the whole jump, so… do that. Once you've manually annotated some track files to explicitly state their exit points, figuring out how to determine each exit point as it's happening is a simpler problem, and it's a problem that can be quantified and iterated on the ground.

(Maybe we should have a repository to collect this sort of information…)

[crwper]

@richo This is something I've been wanting to look at for a while. I have a couple of general suggestions:

1. Unless you're flying right out the door, one possibility is to look for the point where you cross 9.8 m/s vertical speed. This means you've been falling for one second (at least it would if you were in a vacuum), so exit should be about one second before that. The problem with this method is that aircraft sometimes drop this fast, and that could trigger a false exit.
2. When I'm looking for exits manually, the best indicator is a sudden drop in horizontal speed. This occurs very rapidly and immediately on exit, so it can help you nail down the exit timing a lot better than, say, looking at elevation, which changes very slowly right after exit.

The first method might not be too bad if the consequence of a false start isn't too high--e.g., if you have a way to "reset" the system automatically if your algorithm detects that you aren't actually in freefall.

@willglynn What do you have in mind for a repository? One thing I've considered before is to create a repository of "anonymized" FlySight data. To do this, I was thinking of stripping away position data--latitude, longitude and elevation--and perhaps indicating seconds since the start of the file rather than actual date/time. Since FlySight Viewer now has a "logbook", I thought I might add a button somewhere to contribute to this anonymized repository "for the good of science".