er9x development
Re: er9x development
Hi folks,
I don't no if this is the right place to ask this or not.I have the Skyfly TH9X with the SP board and flashed with the FW.My question is I want to buy a heli and use my tx.Will the Skyfly and new FW bind with a heli that has a pcb in it?
Or would the tx work with this heli?
http://www.xheli.com/walkeraheli-v400d02-rtf-lcd.html
I have found a heli that needs this kind of tx.
•Recommended Transmitters
- A 6+ channel DSM2- or DSMX-compatible computer transmitter with helicopter programming
Here>>>http://www.bladehelis.com/Products/Defa ... Id=BLH4580
Could someone tell me if my tx is a DSM2 or DSMX?
Thanks
Tom
I don't no if this is the right place to ask this or not.I have the Skyfly TH9X with the SP board and flashed with the FW.My question is I want to buy a heli and use my tx.Will the Skyfly and new FW bind with a heli that has a pcb in it?
Or would the tx work with this heli?
http://www.xheli.com/walkeraheli-v400d02-rtf-lcd.html
I have found a heli that needs this kind of tx.
•Recommended Transmitters
- A 6+ channel DSM2- or DSMX-compatible computer transmitter with helicopter programming
Here>>>http://www.bladehelis.com/Products/Defa ... Id=BLH4580
Could someone tell me if my tx is a DSM2 or DSMX?
Thanks
Tom
Re: er9x development
Mike,
You could also go after the LCD Reset line as well.
a simple RC reset will work for the Reset line , you get some weird displays as the power turns off.
but other than that , total waste of a port pin.
I left it in the ERSKY board , for more expansion options to a different LCD.
-Brent
You could also go after the LCD Reset line as well.
a simple RC reset will work for the Reset line , you get some weird displays as the power turns off.
but other than that , total waste of a port pin.
I left it in the ERSKY board , for more expansion options to a different LCD.
-Brent
- wheelspinner20
- Posts: 175
- Joined: Tue Dec 27, 2011 6:22 pm
- Country: -
- Location: Michigan, U.S.
Re: er9x development
Hello Tom, and welcome to the rabbit hole that is er9x! We hope you enjoy your journey.Will the Skyfly and new FW bind with a heli that has a pcb in it?
Or would the tx work with this heli?
No, as it is now, it will not bind to a dsm2 or x protocol. BUT we have good news...
Read here. viewtopic.php?f=26&t=163 Dont be offended by the topic title, i don't know you. But I do know you want the capability to bind to all the cool little BNF's out there, so get busy.!
Now, if you would like a link to a fixed pitch 4 channel micro heli that WILL bind to a 9x radio then take a look here: http://www.rcgroups.com/forums/showthre ... xieda+9958 cool little indoor flyer, I own one. That thread will direct you to all the other re-branded versions of the same heli that have rx boards that are bound by flysky protocal.
The Dsm mod does not look too difficult, I will be doing it soon.
Walkera is a different protocal, and will need a different module/receiver to work. BUT I bet if its possible to do, someone will be doing it soon and probably posting somewhere in this forum.
If you have any more question feel free to ask.
Pat
no more quippy little latin phrases.! Its old
Re: er9x development
Hi MikeB,
Thanks for integrating a lot of the code in the project! Happy to help. Sorry for my late answer.
For detecting the battery cell count I do:
This because for some weird reason the high byte is actually store as LSByte in FrskyHubData[6]. I checked this, run different batteries with different cell counts and it's fine. What I do with this code is to AND-out the 4 last bits from the high byte (which is the second one in Frskyhubdata) and then shift them four places to the right, then it is (implicitly) casted to a uint8_t. I checked your version and it doesn't show the cell count properly.
For this same reason when I interpreted the voltage, it's also necessary to shuffle around the bytes:
What I do here is I take the low byte (0xFF00), which is really the MSByte of frskyhubdata and shift 8 places to the right. Then the 4 LSBits of the high byte (0x000F), which is really the LSByte of frskyhubdata are shifted 8 places to the left to have it in the right place. Then just add (or logical OR would work also) both results together. The result is a 12 bit number with the proper placing of all it's bits. I checked with voltages from 2 Volts to 4.2 Volts (2000-4200) and works fine. Doing:
Doesn't work because 1) you are including the also the battery cell count as part of the voltage number and 2) because the high and low bytes are not interchanged.
I know all this is weird, because for all the other frskyhubdata 16-bits values the interpretation doesn't require swapping the high-low bytes. I think this is because the volt sensor is an stm32 microcontroller sending this information in this order to the hub and in the hub, the data is not properly ordered. (A bug in the the frsky hub?)
I hope this clarifies this a bit.
The following code is in er9x.cpp in mainSequence function, near
To put the GPS position in single radians numbers:
If alarm activated then calculate distance to home: (again we could eliminate that variable from the eeprom and only have the GPSDistThreshold variable)
I didn't put the previous code in frsky.cpp frsky_proc_user_byte function because it is so slow that it stops the proper functioning of the whole device (it locks for too long in the RX interruption). It's very slow because it's doing floating point arithmetics and cos, sin, atan2 and sqrt.
Now to set the home position, in menu.cpp:
and to set the GPSDistThreshold just add an additional item in the telemetry menu:
This uses 99.7% of flash space. And I had to change other status screens to save some code space. I don't put this code here for you to include it, but I put it for thinking about it. I like this two additional features a lot, and I think I will leave it in my 9x because for me is very useful and cool .
If somebody finds a way to calculate cos sin atan2 and sqrt with an integer number instead of radians in floating point representation, let me know.
All the best,
Federico
Edit by your friendly MOD to put all code in code tags
Thanks for integrating a lot of the code in the project! Happy to help. Sorry for my late answer.
I agree.MikeB wrote:
I think, rather than have a separate bit and option for an alarm, we might as well be consistent with the other FrSky alarms where if the alarm value is zero, then the alarm is disabled. This will save EEPROM and flash.
Again I agree.I reckon we can use a single byte to store each cell voltage 0-210 to represent 0-4.2V. This will provide a resolution of 0.02V, this should be more than accurate enough and will save RAM.
Yes, I loaded and ran the code. I have the FLVS-01 sensor + the sensor with the upgrade V2 firmware. With the code that I gave you it works. Here it is again:
I've been looking at this, have you loaded the code and run it?
I ask because where you extract the cell number and the cell voltage from the 16 bit value, it does not pick the cell number from the top 4 bits, as specified in the FrSky protocol document. You get it from bits 4 through 7 (0 is least significant bit), not 12 through 15.
FrSky send the bytes with the low byte first, but these are assembled to give a correct 16 bit value. I don't have the cell voltage sensor, so I can't test it.
For detecting the battery cell count I do:
Code: Select all
uint8_t battnumber = ( FrskyHubData[6] & 0x00F0 ) >>4 ;
For this same reason when I interpreted the voltage, it's also necessary to shuffle around the bytes:
Code: Select all
FrskyVolts[battnumber]=2*(((FrskyHubData[6] & 0xFF00) >> 8)+((FrskyHubData[6] & 0x000F) << 8));
Code: Select all
FrskyVolts[battnumber] = FrskyHubData[6] /10 ;
I know all this is weird, because for all the other frskyhubdata 16-bits values the interpretation doesn't require swapping the high-low bytes. I think this is because the volt sensor is an stm32 microcontroller sending this information in this order to the hub and in the hub, the data is not properly ordered. (A bug in the the frsky hub?)
I hope this clarifies this a bit.
That's my mistake, sorry. I also put uppercase for defines always.
As a minor coding note (we don't have a formal coding layout), most of the time #defines are in UPPERCASE. It makes them stand out. So where you have:
#define telemetry_views 6
we would generally put
#define TELEMETRY_VIEWS 6
I agree, I could notice the space problem when I tried to implement the Haversine formula for GPS distance. I couldn't. Not enough space to do too much floting point stuff. I wanted the Haversine formula for calculating the distance between to GPS positions to be able to set an alarm if distance bigger than some threshold. Also I played around with calculating the bearing of the model from home. Here are my changes for this:I know I keep mentioning sapce saving, but by keeping everything as small as possible, we get more functions in. We will have far more space in ersky9x for all this.
I frequently come along after others have done some changes and slim them down
Mike.
The following code is in er9x.cpp in mainSequence function, near
Code: Select all
if (frskyUsrStreaming)
Code: Select all
FrskyGPSLat=((float) ((int32_t) (FrskyHubData[19]/100))*1000000+((((int32_t) FrskyHubData[19])%100)*10000+((int32_t) FrskyHubData[27]))*10/6)*M_PI/180000000;
FrskyGPSLon=((float) ((int32_t) (FrskyHubData[18]/100))*1000000+((((int32_t) FrskyHubData[18])%100)*10000+((int32_t) FrskyHubData[26]))*10/6)*M_PI/180000000;
Code: Select all
if (g_model.FrSkyGPSDistAlarm) {
//For testing :)
//FrskyHomeLat=FrskyGPSLat;
//FrskyHomeLon=FrskyGPSLon+0.000174;
float d_lon=(FrskyGPSLon-FrskyHomeLon);
float d_lat=(FrskyGPSLat-FrskyHomeLat);
float temp= cos((FrskyHomeLat+FrskyGPSLat)/2.0);
FrskyGPSAngle=(atan2(sin(d_lon)*cos(FrskyGPSLat),(cos(FrskyHomeLat)*sin(FrskyGPSLat))-(sin(FrskyHomeLat)*cos(FrskyGPSLat)*cos(d_lon)))*180.0/M_PI);
if (FrskyGPSAngle<0) {
FrskyGPSAngle=FrskyGPSAngle+360;
}
FrskyGPSDist=(sqrt(d_lon*d_lon*temp*temp+d_lat*d_lat) * 6378140);
if (FrskyGPSDist>g_model.FrSkyGPSDistThres) {
audioDefevent(AU_WARNING2);
}
}
Now to set the home position, in menu.cpp:
Code: Select all
case EVT_KEY_LONG(KEY_MENU):// go to last menu
#ifdef FRSKY
if( (view == e_telemetry) && ((g_eeGeneral.view & 0x70) == 0x20 ) )
{
AltOffset = -FrskyHubData[16] ;
}
else if( (view == e_telemetry) && ((g_eeGeneral.view & 0x70) == 0x30 ) )
{
FrskyHomeLat=FrskyGPSLat;
FrskyHomeLon=FrskyGPSLon;
}
else if( (view == e_telemetry) && ((g_eeGeneral.view & 0x70) == 0 ) )
{
Code: Select all
lcd_puts_Pleft(y, PSTR("GPS Dist Thres="));
lcd_outdezNAtt( 21*FW, y, g_model.FrSkyGPSDistThres ,((sub==subN) ? blink:0), 4);
if(sub==subN) {
g_model.FrSkyGPSDistThres=checkIncDec16(event, g_model.FrSkyGPSDistThres,0,5000, EE_MODEL);
}
If somebody finds a way to calculate cos sin atan2 and sqrt with an integer number instead of radians in floating point representation, let me know.
All the best,
Federico
Edit by your friendly MOD to put all code in code tags
- MikeB
- 9x Developer
- Posts: 18010
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: er9x development
I did wonder about the byte order, I have a fix ready, I'll commit sometime, a lopt of changes have gone in recently and I want to check they are all working OK before I do more changes.
We haven't used floating point at all in the code, so as soon as you start to use it you get the floating point package linked in.
You could try things like:
Rather than calculating the sqrt to get the distance and then comparing to a threshold, square the threshold (easier, less code) then do the compare.
Mike.
We haven't used floating point at all in the code, so as soon as you start to use it you get the floating point package linked in.
You could try things like:
Rather than calculating the sqrt to get the distance and then comparing to a threshold, square the threshold (easier, less code) then do the compare.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: er9x development
Please don't quote the post above your post
True, that should work, but if I also want to display the distance in meters in the screen, then we still need the sqrt
F.
True, that should work, but if I also want to display the distance in meters in the screen, then we still need the sqrt
F.
Re: er9x development
We both missed it
It happens. At least we got it fixed quickly.
It happens. At least we got it fixed quickly.
Z
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
Re: er9x development
Hi all,
First thank you very much Erazz and other contributors for the
amazing job you did. I now have a transmitter
that meets all my needs.
Since the latest revisions, the haptic feedback is not working.
I must return to R691 for it to be functional. I tried with
the base version and with the FrSky one, the way my radio is modified. Everything else looks to work normally.
Is this a problem already mentioned?
Regards,
Sylvain.
First thank you very much Erazz and other contributors for the
amazing job you did. I now have a transmitter
that meets all my needs.
Since the latest revisions, the haptic feedback is not working.
I must return to R691 for it to be functional. I tried with
the base version and with the FrSky one, the way my radio is modified. Everything else looks to work normally.
Is this a problem already mentioned?
Regards,
Sylvain.
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
Re: er9x development
I am on the latest version and haptic is working ok?
Any chance you have set the 'vibration strength' very low in the system config page?
Rob
Any chance you have set the 'vibration strength' very low in the system config page?
Rob
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
GPS Distance
About GPS distance: have a look to latest open9x code and feel free to take code from there
It's a rounding valid till about 70° of latitude, but works...
It uses MacLaurin series to calculate cosine of latitude and due to the short range of our flights it also uses sin(x)=x approximation for sin.
The cosine is used to calculate the distance from earth axe at the actual latitude.
This is calculated once whenever GPS fix occurs or we reset starting position and is used to calculate distance when we flight along a parallel.
It's calculated once as we do not flight so distant, in such a way that this value may change significantly during flight
The whole algorithm was written from scratch by me and Bertrand keeping in mind we flight with models, there are also assumptions like the fact that on short distances you may consider land as flat
Due to the fact we stop at the third term of MacLaurin series the precision decreases significantly when we are near the poles, but probably is good for 99% of common usage.
The float point lib is not used, the algorithm uses only uint32.
Overall precision is also rather good: on 100m real distance we had a measure of 99m at 44°N latitude
Regards...
Bertrand & Romolo
It's a rounding valid till about 70° of latitude, but works...
It uses MacLaurin series to calculate cosine of latitude and due to the short range of our flights it also uses sin(x)=x approximation for sin.
The cosine is used to calculate the distance from earth axe at the actual latitude.
This is calculated once whenever GPS fix occurs or we reset starting position and is used to calculate distance when we flight along a parallel.
It's calculated once as we do not flight so distant, in such a way that this value may change significantly during flight
The whole algorithm was written from scratch by me and Bertrand keeping in mind we flight with models, there are also assumptions like the fact that on short distances you may consider land as flat
Due to the fact we stop at the third term of MacLaurin series the precision decreases significantly when we are near the poles, but probably is good for 99% of common usage.
The float point lib is not used, the algorithm uses only uint32.
Overall precision is also rather good: on 100m real distance we had a measure of 99m at 44°N latitude
Regards...
Bertrand & Romolo
Re: er9x development
Hi Rob,
No, same haptic strenght 5, exactly same EEprom values and no reaction of the haptic. And I also tried with another radio I just modified for a friend,
same result! r691 works fine and since r699 it's dead. The mod is exactly as recommended and I use this nice vibration motor
http://www.robotshop.com/ca/solarbotics ... motor.html. If it works for everybody else, I can't understand....
Sylvain.
No, same haptic strenght 5, exactly same EEprom values and no reaction of the haptic. And I also tried with another radio I just modified for a friend,
same result! r691 works fine and since r699 it's dead. The mod is exactly as recommended and I use this nice vibration motor
http://www.robotshop.com/ca/solarbotics ... motor.html. If it works for everybody else, I can't understand....
Sylvain.
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
er9x development
I will have a play next week and try source the problem!
Sent from my iPhone using Tapatalk
Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
Re: GPS Distance
Romolo wrote:About GPS distance: have a look to latest open9x code and feel free to take code from there
It's a rounding valid till about 70° of latitude, but works...
It uses MacLaurin series to calculate cosine of latitude and due to the short range of our flights it also uses sin(x)=x approximation for sin.
Would it be possible to implement the 'distance' feature into the NMEA code?
(sorry, but I don't know C++ to do it by myself )
It would be great, to have it in the lower line of NMEA screen 2/4 .
Actual home position could be saved with home[long] that already saves the actual altitude as home altitude.
Reinhard
Re: GPS Distance
Cool! I'll definetely take a look at it when I get some time. I also saw some code for distance calculation in the cl-osd project.Romolo wrote:About GPS distance: have a look to latest open9x code and feel free to take code from there
It's a rounding valid till about 70° of latitude, but works...
It uses MacLaurin series to calculate cosine of latitude and ...
Regards...
Bertrand & Romolo
Re: GPS Distance
Using the lightweight version for the distance calculation from open9x or cl-osd should be possible. It's a matter of who has the time.ReSt wrote: Would it be possible to implement the 'distance' feature into the NMEA code?
(sorry, but I don't know C++ to do it by myself )
Reinhard
That's exactly how I set the gps home in my test code. This is not a big deal. The problem is with the distance calculation.Actual home position could be saved with home[long] that already saves the actual altitude as home altitude.
- ShowMaster
- Posts: 4327
- Joined: Thu Dec 29, 2011 3:44 am
- Country: -
- Location: Los Angeles, CA USA
Re: er9x development
FYI I flew the latest revision eepe downloaded, r704 and the haptic worked for me. I use it to vibrate when my onboard lipo gets to 11v and then along with the siren sound when it reads 10.8v. It worked that way for me today many flights. Everything seems to be the same as the last revision.hdwf900 wrote:Hi Rob,
No, same haptic strenght 5, exactly same EEprom values and no reaction of the haptic. And I also tried with another radio I just modified for a friend,
same result! r691 works fine and since r699 it's dead. The mod is exactly as recommended and I use this nice vibration motor
http://www.robotshop.com/ca/solarbotics ... motor.html. If it works for everybody else, I can't understand....
Sylvain.
SM
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
Re: er9x development
Silly question...
Do you have the haptic mod that is done using the pin from the cpu to drive the mostor? Or the original version that simply relied on 'long beeps' to fire up the motor?
Rob
Do you have the haptic mod that is done using the pin from the cpu to drive the mostor? Or the original version that simply relied on 'long beeps' to fire up the motor?
Rob
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
Re: er9x development
When should the buzzer be going off for the 2 different mods and also for the different menu settings of quiet/nokey/xshort etc.
I have the pin driven mod. I have my setting to piezospk and nokey. My buzzer is triggering at
center trims
when the voltage alarm goes off
timer hits 30, 20, 10, 0 then keeps going with timer alarm
minute beeps
selecting a new model
mixer alarm 1, 2, 3
creating new model
duplicate model screen
delete model screen
deleting a mix
I have the pin driven mod. I have my setting to piezospk and nokey. My buzzer is triggering at
center trims
when the voltage alarm goes off
timer hits 30, 20, 10, 0 then keeps going with timer alarm
minute beeps
selecting a new model
mixer alarm 1, 2, 3
creating new model
duplicate model screen
delete model screen
deleting a mix
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
Re: er9x development
Those look like the right alert points to me!
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
- MikeB
- 9x Developer
- Posts: 18010
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: er9x development
I've found a few minutes of that 'free time' we've been looking for. I'm slipping in a few minor changes:
The telemetry Fuel display will be a horizontal bar showing how much is left, rather than just a number. I might be able to add a new telemetry screen with some more bars in due course.
When on the main screen, pressing LONG DOWN, will move you directly to the telemetry screens. You will still be able to get to them by the normal up/down sequence. Once there, left/right will still step through the different screens.
When the hub data stream disappears, the last received LAT and LON will still be displayed, but will be flashing to indicate they are NOT updating.
I'm proposing to remove the timer direction option. It does not really serve any useful purpose. The logic will change to:
If the timer value is initialised to zero, then count up.
If the timer value is initialised to NON-zero, then count down.
Does anyone have a problem with this timer change?
Erazz and I have some work proceeding with what is called er9x V2. This will include a major change to the EEPROM structure, partly why its a new version, you will need to know the EEPROM is different, and your current models won't be directly compatible. It is intended to provide a conversion function in eepe. This will all take some time, but hopefully we will be able to add new functions by having extra EEPROM for each model, possibly at the expense of slightly fewer models stored at once.
One change already in and being tested is to have both timers fully triggerable. There is a logical AND function on 2 sources of trigger, so you can include a throttle cut safety switch into the throttle trigger so the timer won't start until the switch is the correct way AND the throttle is advanced. You can aso use any channel output in the same way as TH% is used.
Mike.
The telemetry Fuel display will be a horizontal bar showing how much is left, rather than just a number. I might be able to add a new telemetry screen with some more bars in due course.
When on the main screen, pressing LONG DOWN, will move you directly to the telemetry screens. You will still be able to get to them by the normal up/down sequence. Once there, left/right will still step through the different screens.
When the hub data stream disappears, the last received LAT and LON will still be displayed, but will be flashing to indicate they are NOT updating.
I'm proposing to remove the timer direction option. It does not really serve any useful purpose. The logic will change to:
If the timer value is initialised to zero, then count up.
If the timer value is initialised to NON-zero, then count down.
Does anyone have a problem with this timer change?
Erazz and I have some work proceeding with what is called er9x V2. This will include a major change to the EEPROM structure, partly why its a new version, you will need to know the EEPROM is different, and your current models won't be directly compatible. It is intended to provide a conversion function in eepe. This will all take some time, but hopefully we will be able to add new functions by having extra EEPROM for each model, possibly at the expense of slightly fewer models stored at once.
One change already in and being tested is to have both timers fully triggerable. There is a logical AND function on 2 sources of trigger, so you can include a throttle cut safety switch into the throttle trigger so the timer won't start until the switch is the correct way AND the throttle is advanced. You can aso use any channel output in the same way as TH% is used.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: er9x development
Hope springs eternal..... Mike is by far more efficient than me. But I am working on V2 as well
Z
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
er9x development
Nice .
Sent from my iPhone using Tapatalk
Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
- cre8tiveleo
- Posts: 1434
- Joined: Tue Dec 27, 2011 6:13 pm
- Country: -
- Location: Ontario,(GTA North)
- Contact:
Re: er9x development
TImer... so just to clarify.
If the Timer is set to a value of 0 , then it's automagic to count up.
If I were to choose 5:00 as the timer value , then it will default to count down. No lnger an option to count up or down it's based on what the value of the timer is.
If that's it, then, yeah, I was wonderign why it wasn't done in the first place
Makes total sense.
If the Timer is set to a value of 0 , then it's automagic to count up.
If I were to choose 5:00 as the timer value , then it will default to count down. No lnger an option to count up or down it's based on what the value of the timer is.
If that's it, then, yeah, I was wonderign why it wasn't done in the first place
Makes total sense.
Re: er9x development
Many people (well maybe? at least me ) prefer the count up so they can have a quick look at the screen and see "I've flown 3:40" instead of seeing "I have 5:20 left", but still have the warning at let's say 9:00.MikeB wrote: I'm proposing to remove the timer direction option. It does not really serve any useful purpose. The logic will change to:
If the timer value is initialised to zero, then count up.
If the timer value is initialised to NON-zero, then count down.
Does anyone have a problem with this timer change?
If you remove the direction option that's not possible anymore. If you want the alarm you need to use count-down, which doesn't give you a direct information about how long you've been flying.
Re: er9x development
If there is no way to set a count UP alarm time I don't like that one bit either.
Ted
Ted
- MikeB
- 9x Developer
- Posts: 18010
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: er9x development
Leo: Yes exactly that.
Kilrah: I didn't know that was a possibility! I've always counted down to an alarm.
This is why, at some point in the past, I added the second timer, so you could get an elapsed time, with an alarm on the original timer when it counts down.
Ted: Same as above, I didn't know that worked! But again, there is the second timer to give elapsed time, while the first will beep after a time when counting down.
Mike.
Kilrah: I didn't know that was a possibility! I've always counted down to an alarm.
This is why, at some point in the past, I added the second timer, so you could get an elapsed time, with an alarm on the original timer when it counts down.
Ted: Same as above, I didn't know that worked! But again, there is the second timer to give elapsed time, while the first will beep after a time when counting down.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: er9x development
2 timers to set, 2 timers to reset, the one that counts up is only visible on one screen while the one that is always there is the one that counts down - I vote to keep the up/down optionMikeB wrote:This is why, at some point in the past, I added the second timer, so you could get an elapsed time, with an alarm on the original timer when it counts down.
Ted: Same as above, I didn't know that worked! But again, there is the second timer to give elapsed time, while the first will beep after a time when counting down.
Re: er9x development
Not sure I follow all of that, but would like to continue to have the option as well.
Ted
Ted
- MikeB
- 9x Developer
- Posts: 18010
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: er9x development
I'll leave the option in.
Mike.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: er9x development
MUCH appreciated, thanx!
Ted
Ted