Indicating height of opening

[Kirill Taran]

Why not to add into firmware possibility to indicate when height is under some threshold?
E.g. long constant beep between entering height < 1000m and opening (vspeed < N cm/s).

[Kirill Taran]

Or just put one more setting "height threshold" analogues to "V_Thresh" for disabling FlySight indication on that.

воскресенье, 2 марта 2014 г., 0:19:43 UTC+4 пользователь Kirill Taran написал:

[Michael Cooper]

The main problem with this is similar to the problem with adding audible altitude alarms to the FlySight… The FlySight doesn’t really know what its “height” is—at least not AGL.

 

It would be possible to add a parameter to the configuration file which says what the ground elevation is, and this could be used to calculate heights for things like audible alarms. However, I’m not completely comfortable with this solution. It would be too easy for someone to set everything up at one DZ, then move to another DZ and forget to change the ground elevation.

 

With something like a visual altimeter, you have a clear indication if the altimeter has been zeroed properly, and this is something most people check before they get on the aircraft. Most audible altimeters automatically adjust so that no check is necessary. The problem with FlySight is, without checking the configuration file, there is no obvious way to tell if the ground elevation is set correctly. I suppose we could beep at 1500 feet or so, as some audible altimeters do, but it still seem way too easy to get it wrong.

 

Any thoughts?

 

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/groups/opt_out.

[Kirill Taran]

1. Yes, I agree that adding such feature into commercial product would be bad in the sense of safety.
Otherwise one parameter "height" would be enough (and responsibility about correctness would be on user which should configure it with geo data or exploring log of previous jump).

2. I think it is possible to program FlySight such way that it will determine height over ground in flight according to information got before boarding. (You turn on FS on the ground, FS record height, you turn FS before exit in plane, FS calculates difference.)

But implementation of this is little harder and can contain tricky cases.
E.g. when do you calculate difference?
I suppose that you should search in logs all points with same X and Y but different Z,
then find minimum of them and that should be "zero height".
But obviously if user forgets to enable FS on the ground it will beep on larger height.

3. Maybe I will try to develop such feature in fork according to strategy in par.2.
Though I haven't experience with embedded stuff.

Sincerely,
Kirill Taran

--
You received this message because you are subscribed to a topic in the Google Groups "FlySight Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/flysight-devs/ZH7et15O2SQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to flysight-dev...@googlegroups.com.

[Luke Hederman]

I have actually implemented something similar to this in the Fly-Blind software, although I just use it to silence the navigation below a certain height.
I agree that is is a dangerous feature to add an alarm due to the potential misconfiguration, but have toyed with alarms for entry and exit to competition windows.

In flyblind there is a sanity check that prevents giving any navigation feedback if you are more than x KM from the target point.  This at least lets the user know there is a problem, rather than blissfully flying in a particular direction when the target location is obviously incorrect.  The problem with applying this to an altitude alarm is the user may wait too long for the alarm before realising there is a problem. 

Flyblind is long over due an update, perhaps with the audio file options there are new possibilities such as counting off altitude if near a target location.  Obviously dangerous near mountains!
Michael do you have any changes planned to the main branch in the near future?

[Tom van Dijck]

http://data.geocomm.com/dem/

it's only 56 GB of data ;)... how big does flysight support for the internal SD card?

Ultimately, once you have a lock on GPS, getting the small set of data from the total dataset is relatively easy if organized correctly... And it's not like someone if going to fly from Eloy to Perris in one jump, and even that particular track only covers about 150MB of data from the total set.

A bit of a brute-force approach, but elevation data is available for every square meter of our little blue dot.

Tom.

[Michael Cooper]

I’ve just made a couple of changes—going to a newer version of LUFA (also fixes an error when ejecting on Windows) and adding support for the newer u-blox 7 chipset used in the current round of FlySights.

 

I have two changes planned at the moment…

 

First, I will probably go ahead with the planned repository changes in the next couple of days. I’ve already moved the viewer applications over to their own repositories, and just need to remove them from the main repo and bump the firmware folder up one level.

 

Next… We are still seeing occasional corruptions of the data file on the beta firmware. Ideally, I’d like to take a closer look at the timing on the new audio routines to see if we can get a little more slack in there. Slightly less ideally, I’d simply like to have it fail more gracefully when it runs into a timing issue. I’m hoping to take care of this in the next week or two. That said, it shouldn’t be difficult to merge these changes if you were to go ahead and add navigation to the latest firmware on GitHub.

 

What do you think? I know Spike is really keen to see spoken indications added to the navigation firmware. :-)

[Michael Cooper]

:-) Ah, a new challenge!

 

I know people have had success using microSD cards larger than 2 GB with FlySight. The stock card is just 512 MB, but it’s easily upgraded.

 

Michael

 

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

Sent: March-04-14 3:57 PM
To: flysig...@googlegroups.com

[Luke Hederman]

I'm pretty busy for the next couple of weeks, so I'll wait for your changes and see about making the flyblind code a bit easier to add to to future versions.
I'll see about adding the spoken indication while I'm at it.  I haven't looked at how you've implemented that yet.

[Luke Hederman]

Surely there is a lower resolution dataset available, perhaps even split into hemispheres or other regional blocks?
I've done zero research but have you seen this: http://ned.usgs.gov/downloads.asp
It covers the second most important nation in the world (second to Canada of course)

[Michael Cooper]

It looks like SRTM data is freely available worldwide as well. I’m wondering a couple of things:

 

1.       Suppose we took the raw data and then started eliminating points in a systematic way such that the resulting triangulation results in an error of less than 10 m vertically worldwide—something I’ve done more or less in my “day job”. How much data are we looking at then? What if we divide it into regions?

 

2.       With the right kind of grid, it can be fairly quick to load a particular data point, and even faster if the next point is nearby. Given that the poor little AVR is already pushing pretty hard to speak and log at the same time, I wonder if there is any chance we might be able to eke out just a few more clock cycles and do this kind of lookup.

 

Maybe pie in the sky stuff, but maybe not…

 

Michael

 

From: flysig...@googlegroups.com [mailto:flysig...@googlegroups.com] On Behalf Of Luke Hederman

Sent: March-04-14 4:14 PM
To: flysig...@googlegroups.com

[Tom van Dijck]

Well, this kind of started as a joke actually ;) 

That said, there is a lot of areas that are so flat that you can probably get away with even lower resolution, like 100m or even 1000m resolutions... Really the only areas where high resolution is important is where there suddenly is a mountain sticking out of the ground. So you could potentially make a dataset with LOD maps, and for some areas it the highest resolution map simply isn't there.

Furthermore, for a region where no data is available we can simply turn the feature off, meaning that we can leave it up to the user to select a set of data to put on his flysight... I for example really only fly in Eloy and Perris/Elsinore, and it is not very likely I'll be jumping at a lot of other places. So if I can download a dataset for Arizona and California, I'm pretty much set, and I would bet this is the case for a lot of people.

Anyway, a regular grid is easier to query, but larger in size. So it comes down to how fast we can load data from the SD card, versus cycles spend on a more compressible dataset. 

Tom.

[Tom van Dijck]

Oh and yes, I can probably squeeze out a few cycles here and there.. we're using C in the end, and I bet you there is plenty of opportunity for assembly to take over in some areas and gain a few cycles here and there. I've not looked at the code recently though, so I don't know how it evolved thus far... I don't even have a flysight or any other gear anymore since my garage was emptied by an uninvited guest :(

Tom.

On Tue, Mar 4, 2014 at 3:22 PM, Michael Cooper <mic...@flysight.ca> wrote:

[Kirill Taran]

I have actually implemented something similar to this in the Fly-Blind software, although I just use it to silence the navigation below a certain height.

That is the option because we must give highly distinctive signal; that can be long beep, audio sample or just silencing of other sounds.

http://data.geocomm.com/dem/
it's only 56 GB of data ;)

Actually it's pretty good idea! I forgot about geodata.
Resolution is not big problem: we can load only dropzones, I think they will not take a lot of memory.
Or just give a jumper possibility to load geo data manually.

By the way, I think, for BASE there is no point in implementing such feature. At least "automatic" way
(i.e. with automatic determination of ground elevation) would be pretty dangerous and it would be better
to give opportunity to jumper to decide when exactly FS must signalize in every specific case.

Sincerely,
Kirill Taran

--
You received this message because you are subscribed to a topic in the Google Groups "FlySight Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/flysight-devs/ZH7et15O2SQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to flysight-dev...@googlegroups.com.

[Yorick]

As a user I would like the feature to have accurate alarms. Not for brake off but like a competition window. I tested it also during canopy filght, and that works also quite good. But ultimately we also have audibles to warn us at break off.

So I would turn this feature off by default. A user can then enable it.
The way I do it now, is just keep a 'dropzone file' and copy/paste all the info from that file when I arrive at that dropzone. If i'n new at a dropzone, I just walk with the flysight to the landing area and then copy paste from the log file. (I can image that if we make a google doc, we can get the data of the most commonly used dropzones pretty quickly together. ^_^ )

I used the flysight with the latest software this weekend while backflying.

Two things that are more important for me right now:
1) Spoken indications in combination with flyblind;
2) The volume for spoken indications and the tones seems different and a little out of balance. (if it's just me, just ignore this) When I used in-earphones, the volume on the tones was quite right (on '0') but the spoken tekst was to loud. I'm still struggling a bit to get the perfect headphones in combination with the right volume.

-Yorick

[Michael Cooper]

Hi Yorick—

 

Ton answer your two big questions:

 

1.       I believe Luke will be working on merging the “speech” firmware and FlyBlind in the next few weeks.

2.       With the latest firmware (on GitHub) you should find that the “Volume” adjustment affects both speech and tones. Previously it affected only the tones.

 

I expect I’ll be revisiting the “alarm” question in the next few weeks. I think it will be possible to add, e.g., a dropzone elevation in the configuration file so that alarm elevations can be specified relative to that. My main concern is that someone might forget to adjust the dropzone elevation in the configuration file when they move to another dropzone… Alas, I’m not sure there is a reliable way for us to detect dropzone elevation automatically, since the FlySight is not left on all day.

 

Michael