Author Topic: Model Airplane Pylon Judging System  (Read 12138 times)

delateurj

  • Newbie
  • *
  • Posts: 14
Re: Model Airplane Pylon Judging System
« Reply #15 on: February 04, 2015, 12:02:43 AM »
Quick update:

Tried a really basic (too basic) token approach and that did not help primarily as my approach didn't consider the fact (now obvious) that acks can fail as well as they are just another very short message.

Tightened up my debugging code so I only reported out final results to flash when a test run was done.  Eliminated all debug communication to serial port or to I2C based OLED.  This combined with doing open air test, 3 judge ground units within inches of each other, judge repeater 3 feet away, light repeater 75 feet from judge repeater and light ground unit 3 feet from light repeater and drumroll please.....

10,000 messages with no failures end to end.  Detailed stats: Approximate 1.3% of messages require 1 retry, .2% 2 retries, .1% 3-4 retries, never needed more than 4 retries except one message. 

Did a similar test with xbee's with slightly better results but 900mhz versions you cannot directly control retry time.  Sticking with Moteino. I am guessing better because ack is hardware based.

Need to consider fact that ack can fail  in messaging design (light ground unit actually received 10047 messages when 10000 attempted due to ack failures. Not a problem.

One thing I need to think through is that if I go with 5 or 6 retries with a 25 ms retry time and use send with retry which is blocking, I could miss a quick button press by the person (press and release in less 100 ms).  I may modify library to pass a function pointer to call function between retries so I can check state of button between retries so I don't miss button press.  There are hardware options to extend the length of button press (simplest using capacitor) but rather do in software and my board design otherwise is working a good and would rather not rev again.

Made first fully functional set of components for a simpler type of racing where I all I need is a single lap counter to display the number of laps completed and when done displays total time to complete race.  This took one afternoon using the carrier boards I described above including the Arduino Moteino shield I made so I could control Freetronics DMD display via Uno.

Regards,
Joe.
« Last Edit: February 04, 2015, 12:04:43 AM by delateurj »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5934
  • Country: us
    • LowPowerLab
Re: Model Airplane Pylon Judging System
« Reply #16 on: February 04, 2015, 08:14:45 AM »
Tightened up my debugging code so I only reported out final results to flash when a test run was done.  Eliminated all debug communication to serial port or to I2C based OLED.  This combined with doing open air test, 3 judge ground units within inches of each other, judge repeater 3 feet away, light repeater 75 feet from judge repeater and light ground unit 3 feet from light repeater and drumroll please.....

10,000 messages with no failures end to end.  Detailed stats: Approximate 1.3% of messages require 1 retry, .2% 2 retries, .1% 3-4 retries, never needed more than 4 retries except one message. 

Did a similar test with xbee's with slightly better results but 900mhz versions you cannot directly control retry time.  Sticking with Moteino.

This is so fantastic ....

TomWS

  • Hero Member
  • *****
  • Posts: 1888
Re: Model Airplane Pylon Judging System
« Reply #17 on: February 04, 2015, 08:38:35 AM »
Quick update:

Tried a really basic (too basic) token approach and that did not help primarily as my approach didn't consider the fact (now obvious) that acks can fail as well as they are just another very short message.
Yeah, Acks aren't ack'd...
<...snip>
10,000 messages with no failures end to end.  Detailed stats: Approximate 1.3% of messages require 1 retry, .2% 2 retries, .1% 3-4 retries, never needed more than 4 retries except one message. 
Coool!
Need to consider fact that ack can fail  in messaging design (light ground unit actually received 10047 messages when 10000 attempted due to ack failures. Not a problem.
I've wondered about Acks on Acks, but that seems such overkill.  There are spare control bits that COULD be used to indicate an Ack on Ack, but I'm not sure how much you'd want to pursue that.  Seems like extra packets aren't too big an issue in your case, except...
One thing I need to think through is that if I go with 5 or 6 retries with a 25 ms retry time and use send with retry which is blocking, I could miss a quick button press by the person (press and release in less 100 ms).  I may modify library to pass a function pointer to call function between retries so I can check state of button between retries so I don't miss button press.  There are hardware options to extend the length of button press (simplest using capacitor) but rather do in software and my board design otherwise is working a good and would rather not rev again.
I'd look into Interrupt on pin change: PinChangeInt library - you'd catch and save your button changes in an interrupt handler.
Made first fully functional set of components for a simpler type of racing where I all I need is a single lap counter to display the number of laps completed and when done displays total time to complete race.  This took one afternoon using the carrier boards I described above including the Arduino Moteino shield I made so I could control Freetronics DMD display via Uno.

Regards,
Joe.
Pretty cool, Joe.  Good work!

Tom