billyd60 - looks similary (Zbig's have a better resolution), I use both. Quite other targets.

Zbig - what's new with airspeed measurments and usage in AP?

For two weeks OSD supports airspeed microsensor 3.0 from EagleTree.
(so far we don't have own sensor - I've just tried available sensor from HobbyKing)
We support it in "OEM" mode, so no special configuration is needed. It works "out of the box".
One can connect sensor into OSD using I2C socket. Of course ET sensor's connector is not pin-to-pin compatible with OSD, so one have to change connector and wire order.
Wires mapping is as follow:

(sensor -> I2C port)
White  -> Gnd 
Red    -> Vcc (+5V)
Brown  -> CL
Yellow ->DA

OSD can show airspeed in "framed" speed field on left ruler, and "text" speed field is still available for GPS (ground relative) speed.

When airspeed is turn ON in layout designer in appropriate field properties
[x] airspeed
there will be white triangle mark inside field frame, indicating airspeed measurements instead of GPS speed (see attached picture).

So far I've made only several flights (approx 2h in total) with airspeed, so it wil be still considered as "BETA", until other testers confirm it works as expected.

Originally Posted by Zbig

For two weeks OSD supports airspeed microsensor 3.0 from EagleTree.

Great
The first step to higher level was made
Airspeed (IAS) let You warn and control stall.
What next? - i think:
1. calibration of stall speed in AP (in flight tests)
2. calibration of optimal speed (analizing current and IAS) in flight - and set it as cruise speed.
3. Create the algorithm how the AP should work to avoid stall

Originally Posted by krall

Airspeed (IAS) let You warn and control stall.

It's common misconception. Stall is all about angle of attack.
For real airplanes, which are fast, it can be quite easily replaced by "stall speed".
But our airlanes are slow, e.g my SkySurfer glide speed is 8m/s and reaching air current with 1m/s vertical speed (not so much indeed) will cause change in angle of attack equal 7 degree! (The critical angle of attack is typically about 15 degrees).

For airplane speed 100km/h = 27m/s, similar situation causes only 2 degre change in angle of attack - no serious problem.

Fortunately our airplanes will react for this situation levering tail up thus reducing angle of attack - but it is no case, when stabilisation is "ON" - airplane will keep pitch unchanged. Of course Relatively lightweight airplane will in short period of time gain vertical speed reducing again this angle, but still - stall is not only matter of airspeed.

Of course one can set "stall speed" with enough ( it means big) arbitrary margin to cover this situation. But in fact keeping airspeed with arbitrary margin is nothing else than keeping throttle in arbitrary level, isn't it?
So what sense is to employ sensors and quite complicated alghoritm instead of using simple solution?

Zbig,

All what you said is true
But look at model flying a little bit wider, not only as small slow foam plane.

E.g. I have Cularis (also foam ;-) ) - this plane likes speed, spin is no problem when You fly too slow (yes - angle of attack too high or plane in too big tilt).
When You fly FPV and control IAS and AoA spin probability is lower.
Sometimes better is to add throttle sometimes nose down.
I piloting also a little bit bigger planes and look at this question maybe a little other (in cessna i have accoustic stall warning)
Analyzing IAS and AoA, eventually tilt AP may warn "STALL" - also in manual mode
E.g. - In AUTO mode - flying to WP on (to) set altitude with optimal speed (optimal not on throttle limit) AP should analyze data from all sensors and adjust throttle and pitch depending on situation.

I know that's sounds a little bit too complicated and You may said "it have no sense"
But imho basic functionality was achieved. Now you may stop or extend AP functionality of some features like this :-)

I want back to font:

Originally Posted by Zbig

Font is 12px height x 10px width for each character. There is no variable -sized letters (or kerning). So far there is only one set.
Other font is possible, of course it need to be defined in pixel-by-pixel basis (I hate such a work).
Due to font body (black) and outline (white) it can't be made much smaller, but 11x9px or probably 10x9px will be possible. It makes it only 10% smalller, without real harm to its appearance. Here is original 12x10 and reduced 11x9 sample letters:

As you can see vertical lines in font are 2px width. This is because of aspect ratio of pixels - it is not exactly 1:1 (rather 4:3), and very thin lines will be hardly legible in tough conditions. This gives also effect of thick body of font with thin outline, which looks better.
According to font size there will be also changes in designer, according to new "field" sizes.
Changing font for whole screen seems to be quite straightforward, but mixing them in one layout may be more difficult and will require far more work.

Zbig, sorry, but I dont get it.
What "field" size of fonts is now px x px?
It is an obvious that this area have to cover gap between each font and outline.
For simplify: assume that por PAL it is 720×576px.
Font size 72x57
than we can put 10x10 fonts - this is what I understend.
Is it correct that in 72x57 will be 1st "field" size and 36x27 2nd "field" size?

Originally Posted by Zbig

Speaking of layouts number, removing fixed layouts is simplest task, but I agree: for customer it is better to add something rather than remove :-) I'll think about it.

Grate, greate, grate, I hope positive (4 user customizable layouts)

Rufio,
Forget about PAL resolution, OSD has its own resolution, smaller than PAL or NTSC,
due to additional margins (to avoid clipping by some displays) and internal rendering alghoritms.
Printable area is only 400x250px in PAL and 400x205px in NTSC.
Inside this area you can put text (characters) at any location (offset) you want (in 1px resolution). There is no fixed positions for characters.
Now you can put 40 consecutive letters in one row of text, and 20 rows of text in PAL or 17 rows in NTSC.
So only limitation for additional (smaller) fonts is their minimal legible size. As shown on picture one can't make letters much smaller, because they are already small (12x10px bounding box of each letter).

Krall,
Of course knowing airspeed gives additional opportunities to AP functionality.
AP can be a little bit "samarter". There is no simple way of calculating angle of attack based on available sensors. But probably some "estimation" will be possible.
But talking about angle of attack, it seems to be quite easy to make sensor similar to ones in "real" airplanes, which can "switch on" when angle reaches particular value.
I've build some prototypes of such sensor, but no test were performed so far.


btw. BETA version of new software was published today for testers.
Good news: New firmware contains 4 full user-configurable layouts.

Hello
Anyone know the website of PitLab, can I can not go.
many Thanks

Today Pitlab's website is experiencing some problems and do not respond .
I hope it will be solved soon.

For your reference:

Wbsite:
http://www.pitlab.com

Latest software updates and manuals:
http://www.pitlab.com/download-fpv

Shop:
http://www.pitlab.com/pitlabshop

For Polish customers:
http://www.pitlab.pl

Thanks,
We'll try later

Originally Posted by PepeTony

Anyone know the website of PitLab, can I can not go.

I am sorry for it. The hosting provider suspend my account from unknown reason. It was happen in Saturday morning - worst possible time -2 days without service.
The provider doesn't answer telephone nor e-mail. Most probably I have to wait until Monday.
This is clear sign to change provider...

ps. Also e-mail to me does't work. If somebody has something urgent to me I am available at alternative email: pitlab@wp.pl

Hello,
Do not worry, I hope this soon accessible your web, I'm new to your products but I have really enjoyed. Greetings from Spain
thanks

Pitlab's websites are now alive.

Not only Pitlab has experienced troubles this weekend.
Late in saturday, central heating in my house has stoped working. Termometer shows -14C ( 7F )
As far as I can recall, all mailfunctions of my heating were always on saturdays

As Zbig announced the PitLab.Shop is online again. Reason of problem was reaching 10 GB of monthly transfer.
Problem is solved for some time until transfer will reach 20 GB :-)

During this time we added to shop's offer 2 sensors for OSD:
Temperature sensor -40 +57°C for OSD
Temperature sensor -40 +125°C for OSD

Amazing work! It looks like this OSD/AP has everything that can be needed. I'm airliner pilot and the thing that has more surprised me is the reliability of the artificial horizon display. I've seen a lot of OSD and even those equipped with IMU (such has RVOSD5 or DragonOSD) show bugs in the display. Sometimes roll indication shift and is not parralèle to the real horizon and so on....

But on your OSD everything seems to be reliable and the price isn't so high compared to other OSD with similar caracteristics.
Congratulations

Originally Posted by Zbig

For real airplanes, which are fast, it can be quite easily replaced by "stall speed".

No, no, no...Don't beleive that! Even on big aircrafts such has liners or fighters we use angle of attack to determine stall margin. All stall warning système use AOA sensor. Using Airspeed for that kills people every year on light aircrafts. The "stall speed" is not single. As it depends on load factor, it is for exemple double under 4G! A simple turn with a bank of 60° increases "stall speed" by a factor of 1,4.
Of course you can use speed as far as you don't sustain more than 1 G load factor, on final for example, but as you can not be sure that G load will not increase (manoeuvre, updrift, windshear etc...) you have the to increase the "1g stall speed" by 1,3 on final to be seriously protected against stall.