Recent development

[Michael Cooper]

Hi All—

 

I’ve been doing a bit more work on the FlySight firmware in the past couple of days. Mostly, I’ve been working out the timing for 10 Hz logging + speech. With the current GitHub firmware, units with serial number 1247 and higher will be able to log at 10 Hz with no errors. At the same time, the speech functionality is largely flawless.

 

There is one problem that remains with speech: With a sample rate of 31250 kHz and a 512 sample buffer, the longest delay we can currently handle is about 16 ms. This is mostly good enough, but occasionally we see delays as high as 25 ms or so—possibly when crossing cluster boundaries, though I’m not sure about that since the effect doesn’t seem consistent when speaking a particular digit. There are a couple of possible solutions to the problem:

 

1.       If it is, indeed, caused by delays in the microSD card, then we would need to increase the size of the audio ring buffer. If we double the size of the buffer to 1024 bytes, this should give us a tolerance of 32 ms, which would cover any delay I’ve seen in testing. However, we’re running a bit short on memory at the moment, so I don’t think it will be possible to increase the ring buffer size without a bit more optimization.

 

2.       Alternatively, the problem may not be intrinsic to the microSD card. Perhaps the problem is caused by a timing issue, e.g., within FatFS, in which case we might be able to get around it without increasing the ring buffer size.

 

For the moment, though, speech seems to be quite functional. If you’ve been using it already, then you’ve most likely been working with a much less efficient buffer than the one that’s in place now, so if you haven’t noticed any flaws in the speech (or only a few flaws) then you should notice even fewer now. Importantly, the logging function now has its own ring buffer which should prevent any missed samples or “long lines” that were causing problems in the past.

 

There is one other issue that I wanted to put out there for discussion. The current GitHub firmware acts as a “composite” device when plugged into a USB port. It will act as both a mass storage device (as it has in the past) and a serial GPS. This allows you to connect directly to the GPS receiver using software on your PC, e.g., to use it for navigation. The only problem is this: With FlySight acting simply as a mass storage device, we could rely on the system’s built-in drivers. However, if we make it a composite device, we need to provide a driver. From a development standpoint, drivers can be a bit of a pain, but I think the bigger problem here is on the user’s end of things. Setting up drivers isn’t too hard for an experienced user, but a lot of the people who are using FlySight aren’t that experienced—so perhaps simpler is better.

 

What I’m wondering is this: Does the difficulty of using drivers outweigh the utility of the serial interface? If FlySight acts as a composite device, then *neither* interface shows up until the drivers are installed, so it’s not like the user can operate on partial functionality until the install the driver. What do you think?

 

Michael

[Will Glynn]

On Apr 30, 2014, at 12:14 PM, Michael Cooper <mic...@flysight.ca> wrote:

> If FlySight acts as a composite device, then *neither* interface shows up until the drivers are installed, so it’s not like the user can operate on partial functionality until the install the driver. What do you think?

I'd like to add that this behavior is specific to Windows. (Mac OS X and Linux both recognize composite FlySights and enable mass storage + serial interfaces without needing drivers.) This is still significant, of course, but it's not as if we need to build and ship drivers for FlySight to work on any platform, and even the Windows drivers are code-less .INF files.

--Will

[Michael Cooper]

:-) Microsoft has actually made the situation slightly worse with Windows 8.1. I haven't had a chance to experiment with it myself, but another user reported that Windows 8.1 insisted on loading a driver for the "Qualcomm Gobi 2000" and wouldn't allow the driver to be updated. That's the kind of thing that makes me nervous about shipping drivers, as long as we know that the FlySight won't work at all unless the drivers can be installed...

I believe Windows 8 has some kind of driver signing mechanism in place as well, so there are a few more hoops to jump through to get the driver recognized by the system.

I think the first step will be to see if we can make the drivers work "easily" on Windows.

Michael

--
You received this message because you are subscribed to the Google Groups "FlySight Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flysight-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Will Glynn]

On Apr 30, 2014, at 1:09 PM, Michael Cooper <mic...@flysight.ca> wrote:

> I think the first step will be to see if we can make the drivers work "easily" on Windows.

Agreed. I wrote that changeset and found that everything Just Works™ on my systems. I had no idea it made everything difficult on Windows. If it sucks, we should explore alternatives.

Besides navigation, having a USB serial device that talks straight to the GPS module also permits other features: upgrading the u-blox firmware, AssistNow, etc.
http://www.u-blox.com/en/assisted-gps.html

--Will

[Tom van Dijck]

> With a sample rate of 31250 kHz and a 512 sample buffer, the longest delay we can currently handle is about 16 ms.

For speech?? 31.2 kHz seems overly excessive, you could be playing some of the better guitar solos on that... 

8kHz should be sufficient for perfectly recognizable speech, at 8kHz, you get 4 times the buffer time at 64ms, even at 16kHz you'd get 32ms.

Just to quote from here:

http://en.wikipedia.org/wiki/Voice_frequency

"In telephony, the usable voice frequency band ranges from approximately 300 Hz to 3400 Hz."

and:

"The voiced speech of a typical adult male will have a fundamental frequency from 85 to 180 Hz, and that of a typical adult female from 165 to 255 Hz."

As for the driver thing, while I have not tried this at all... I think it would be a pretty big barrier to entry for people to require the installation of a driver. For something that wasn't needed prior, it seems like a step backwards in usability for windows users... It sucks really, because I don't like windows lately either, but the fact is unfortunately that a big part of your user base are windows users.

Also, it would be really cool if someone wrote an android app for flysight... It should be possible to connect the device to the phone with a USB cable, I haven't tried this yet though..

Tom.

Tom.

--

[Michael Cooper]

That’s a really good point…

 

We would want to stick with a PWM rate of 31.25 kHz because it puts the PWM frequency out of audible range. However, perhaps we can update it every other sample instead of every sample or even, as you suggest, less frequently than that.

Michael

 

From: flysig...@googlegroups.com [mailto:flysig...@googlegroups.com] On Behalf Of Tom van Dijck

Sent: April-30-14 2:59 PM
To: flysig...@googlegroups.com

[Tom van Dijck]

Not to be anal, but to go out of the audible range you'd have to sample at 40kHz..

"The human range is on average from 20 to 20,000 Hz,"

For some people you'd have to even go higher, which is one of the reasons why CD's are traditionally sampled at 44.1kHz, and even at that rate there is people that claim to hear the aliasing..

I mean, my ears are fucked.. but I can definitely still hear 16kHz, so a 31kHz sample rate does not get you what you are expecting.

Anyway, skipping samples as you suggest, would effectively bring down the sample rate either way, so I'm not sure you'd be maintaining the audible range in that case. But I'm not 100% sure what you mean with maintaining PWM rate..

Tom.

[Michael Cooper]

:-) Sure—but the issue here isn’t sampling.

 

The problem is that PWM has a base frequency. Every 256 clock ticks the PWM counter resets. From that point, the output spends a certain amount of time at the high state before it drops low for the rest of the cycle. The average over the cycle is your sample value, but there’s still the underlying PWM frequency—in this case 31.25 kHz—to deal with. If you used a much lower PWM frequency—say, 8 kHz—you would hear the audio you intended to output, but you’d also hear an 8 kHz tone in the background.

 

To deal with that tone, you will sometimes install a low-pass filter to eliminate the PWM frequency while retaining the average value. However, in our case there are a couple of other considerations:

 

1.       The earphones are a significantly inductive load, so they act as a bit of a low-pass filter anyway.

2.       If we can push the PWM frequency past the range of human hearing, then it doesn’t really matter if it’s filtered or not.

 

If you connect the FlySight to a decent pair of earphones, they will probably retain some of that 31.25 kHz PWM frequency, since they have a fairly flat response out to 20 kHz. But since you can’t hear it, it doesn’t really matter. The goal with keeping the same PWM frequency but skipping samples would be to retain these filtering effects while reducing the sample rate of the audio.