er9x development

er9x is the best known firmware. It has a superb range of features and is well supported by the community. Well worth trying out.
User avatar
deadaim57
Posts: 46
Joined: Wed Dec 28, 2011 1:22 am
Country: -
Location: Winnfield.Louisiana

Re: er9x development

Post by deadaim57 » Mon Feb 06, 2012 8:48 pm

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


SkyNorth
Posts: 958
Joined: Tue Dec 27, 2011 11:40 am
Country: -
Location: Mansfield , Ontario

Re: er9x development

Post by SkyNorth » Mon Feb 06, 2012 9:14 pm

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

User avatar
wheelspinner20
Posts: 175
Joined: Tue Dec 27, 2011 6:22 pm
Country: -
Location: Michigan, U.S.

Re: er9x development

Post by wheelspinner20 » Mon Feb 06, 2012 10:27 pm

Will the Skyfly and new FW bind with a heli that has a pcb in it?
Or would the tx work with this heli?
Hello Tom, and welcome to the rabbit hole that is er9x! We hope you enjoy your journey.

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

memeruiz
Posts: 6
Joined: Fri Feb 03, 2012 12:01 am
Country: -

Re: er9x development

Post by memeruiz » Mon Feb 06, 2012 11:05 pm

Hi MikeB,

Thanks for integrating a lot of the code in the project! Happy to help. Sorry for my late answer.
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.
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.
Again I agree.

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.
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:

For detecting the battery cell count I do:

Code: Select all

uint8_t battnumber = ( FrskyHubData[6] & 0x00F0 ) >>4 ;
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:

Code: Select all

FrskyVolts[battnumber]=2*(((FrskyHubData[6] & 0xFF00) >> 8)+((FrskyHubData[6] & 0x000F) << 8));
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:

Code: Select all

FrskyVolts[battnumber] = FrskyHubData[6] /10 ;
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.

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
That's my mistake, sorry. I also put uppercase for defines always.
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 :mrgreen:

Mike.
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:

The following code is in er9x.cpp in mainSequence function, near

Code: Select all

        if (frskyUsrStreaming) 
To put the GPS position in single radians numbers:

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;
If alarm activated then calculate distance to home: (again we could eliminate that variable from the eeprom and only have the GPSDistThreshold variable)

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);
	      }
	    }
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:

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 ) )
        {
and to set the GPSDistThreshold just add an additional item in the telemetry menu:

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);
  }
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

User avatar
MikeB
9x Developer
Posts: 16560
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: er9x development

Post by MikeB » Tue Feb 07, 2012 12:04 am

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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!


memeruiz
Posts: 6
Joined: Fri Feb 03, 2012 12:01 am
Country: -

Re: er9x development

Post by memeruiz » Tue Feb 07, 2012 12:11 am

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.

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Tue Feb 07, 2012 1:59 am

We both missed it :)
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!

hdwf900
Posts: 4
Joined: Sat Dec 31, 2011 3:05 am
Country: -
Location: Montreal, Quebec, Canada.

Re: er9x development

Post by hdwf900 » Thu Feb 09, 2012 8:34 pm

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.

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: er9x development

Post by Rob Thomson » Thu Feb 09, 2012 8:53 pm

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
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!

Romolo
9x Developer
Posts: 1109
Joined: Sat Dec 31, 2011 12:11 am
Country: -
Location: Massa (MS), Tuscany, Italy

GPS Distance

Post by Romolo » Fri Feb 10, 2012 12:12 pm

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

hdwf900
Posts: 4
Joined: Sat Dec 31, 2011 3:05 am
Country: -
Location: Montreal, Quebec, Canada.

Re: er9x development

Post by hdwf900 » Sat Feb 11, 2012 3:26 pm

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.

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

er9x development

Post by Rob Thomson » Sat Feb 11, 2012 3:49 pm

I will have a play next week and try source the problem!


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!

ReSt
Posts: 1514
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: GPS Distance

Post by ReSt » Tue Feb 14, 2012 12:05 pm

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 :cry: )

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

memeruiz
Posts: 6
Joined: Fri Feb 03, 2012 12:01 am
Country: -

Re: GPS Distance

Post by memeruiz » Fri Feb 17, 2012 12:44 pm

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
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.

memeruiz
Posts: 6
Joined: Fri Feb 03, 2012 12:01 am
Country: -

Re: GPS Distance

Post by memeruiz » Fri Feb 17, 2012 12:50 pm

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 :cry: )

Reinhard
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.
Actual home position could be saved with home[long] that already saves the actual altitude as home altitude.
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.

User avatar
ShowMaster
Posts: 4327
Joined: Thu Dec 29, 2011 3:44 am
Country: -
Location: Los Angeles, CA USA

Re: er9x development

Post by ShowMaster » Sat Feb 18, 2012 7:30 am

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.
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.
SM

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: er9x development

Post by Rob Thomson » Wed Feb 22, 2012 7:22 am

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
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!

User avatar
Crucial
Posts: 581
Joined: Tue Dec 27, 2011 6:56 pm
Country: -
Location: SE WI, USA

Re: er9x development

Post by Crucial » Thu Feb 23, 2012 9:48 pm

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

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: er9x development

Post by Rob Thomson » Fri Feb 24, 2012 6:55 am

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!

User avatar
MikeB
9x Developer
Posts: 16560
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: er9x development

Post by MikeB » Thu Mar 01, 2012 3:43 pm

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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Thu Mar 01, 2012 5:34 pm

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!

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

er9x development

Post by Rob Thomson » Thu Mar 01, 2012 5:55 pm

Nice :).


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!

User avatar
cre8tiveleo
Posts: 1434
Joined: Tue Dec 27, 2011 6:13 pm
Country: -
Location: Ontario,(GTA North)
Contact:

Re: er9x development

Post by cre8tiveleo » Thu Mar 01, 2012 5:57 pm

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 :D

Makes total sense.

User avatar
Kilrah
Posts: 10186
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: er9x development

Post by Kilrah » Thu Mar 01, 2012 8:19 pm

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?
Many people (well maybe? at least me :D ) 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.
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.

G550Ted
Posts: 389
Joined: Tue Dec 27, 2011 6:15 pm
Country: -
Location: Savannah, GA, USA

Re: er9x development

Post by G550Ted » Thu Mar 01, 2012 9:07 pm

If there is no way to set a count UP alarm time I don't like that one bit either.

Ted

User avatar
MikeB
9x Developer
Posts: 16560
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: er9x development

Post by MikeB » Thu Mar 01, 2012 9:27 pm

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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
Kilrah
Posts: 10186
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: er9x development

Post by Kilrah » Thu Mar 01, 2012 9:57 pm

MikeB 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.
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 option ;)

G550Ted
Posts: 389
Joined: Tue Dec 27, 2011 6:15 pm
Country: -
Location: Savannah, GA, USA

Re: er9x development

Post by G550Ted » Sat Mar 03, 2012 3:18 am

Not sure I follow all of that, but would like to continue to have the option as well.

Ted

User avatar
MikeB
9x Developer
Posts: 16560
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: er9x development

Post by MikeB » Sat Mar 03, 2012 1:19 pm

I'll leave the option in.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

G550Ted
Posts: 389
Joined: Tue Dec 27, 2011 6:15 pm
Country: -
Location: Savannah, GA, USA

Re: er9x development

Post by G550Ted » Sat Mar 03, 2012 2:49 pm

MUCH appreciated, thanx!

Ted


Post Reply

Return to “er9x”