Here's a quick update about my attempt to get the code to read from various ESC without worrying about the timing issue previously discussed.
I hope to have code to post later today but for now I wanted to show the results of my code to read the bits from the time intervals.
Hopefully this output will let you see what the code is doing.
Pulses (in milliseconds)
[0] 2.537, 2.530, 5.041, 5.077, 2.532, 2.530, 2.532, 2.530, 2.532, 2.568
[10] 2.532, 2.530, 5.041, 2.530, 15.231, 7.200,
Parsing the time into data.
ParseTimes
Finding the bit values from pulse times.
16 pulses were received.
Time expected for each bit = 2.500 ms *** Default Bit Width ***
First pulse low
1 low bits, raw packet with new bits = %0
1 high bits, raw packet with new bits = %01
No bit timing errors detected.
The new expected time is the average pulse length of the first two bits/pulses.
Time expected for each bit = 2.533 ms
2 low bits, raw packet with new bits = %0100
2 high bits, raw packet with new bits = %01_0011
1 low bits, raw packet with new bits = %010_0110
1 high bits, raw packet with new bits = %0100_1101
1 low bits, raw packet with new bits = %0_1001_1010
1 high bits, raw packet with new bits = %01_0011_0101
1 low bits, raw packet with new bits = %010_0110_1010
1 high bits, raw packet with new bits = %0100_1101_0101
1 low bits, raw packet with new bits = %0_1001_1010_1010
1 high bits, raw packet with new bits = %01_0011_0101_0101
2 low bits, raw packet with new bits = %0100_1101_0101_0100
1 high bits, raw packet with new bits = %0_1001_1010_1010_1001
6 low bits, raw packet with new bits = %010_0110_1010_1010_0100_0000
3 high bits, raw packet with new bits = %01_0011_0101_0101_0010_0000_0111
rawRxPacket = %00_1001_1000_0111
rxPacket = %11_1000_0110_0100
The program uses the first two bits received to reset the bit timing. This timing reset isn't really needed since timing errors no longer accumulate. Each high or low pulse is parsed into the bits one pulse at a time (after all the pulses have been captured).
Anyway, I think it's kind of a cool way to capture bits.
Probably won't get back to this until I get back from the Boston Expo.
Took my first flight last night with hover training as usual. Was fine for 10 minutes, then the copter went crazy and headed for my unprotected leg, (wearing shorts, those props are sharp!).
The unit ended up upside down with the props spinning, even thought the throttle was cut to 0.
Going to leave it together to show at the expo, and then tear it down and do all the calibrations again, along with the ECS throttle calibration.
Ouch! That kind of sucks. Got to wonder how the motors kept running with the throttle cut, unless somehow the control went haywire. Maybe you accidentally hit a radio switch in the heat of the moment? I've crashed a number of times and have always been able to cut the throttle before impact.
How did you get the props stopped? Pulling power around spinning props wouldn't be fun either.
Surely you have broken props? Hopefully no bent motor shafts.
I did have one equipment failure, one ESC went belly-up. Of course it resulted in an instant flip and subsequent crash. In that case also the throttle continued to work fine. (not that it did a lot of good )
I'll bet your 10 minutes were fun. Hope you find the source of the problem and get back in the air soon.
This version has a lot of debug statements. I'll clean them out after the code as been tested a bit. If any of you can find bugs, it would help if you would also cut and paste what's displayed in the terminal window and post it with the bug report.
The timing differences between ESCs shouldn't be a problem anymore.
What was previously the "From ESC" will still display the data read from the ESC unless data had been transmitted since the last time data had been read. If the last data exchange was sending data then the column contains the settings last "Sent To ESC".
Here's a sample screen:
BuildParameterWord
txPacket = %00_0000_0000_0000
current selection = %00_0000_0000_0000
rxPacket = %00_0010_1101_0111
The current parameter settings match the settings transmitted to the ESC.
You should not need to transmit parameters unless a change is made to the current settings.
programName = ESC-Programmer140804f
par# 0 1 2 3 4 5 6 7
rx = 1, 1, 1, 2, 2, 2, 0, 1
tx = 0, 0, 0, 0, 0, 0, 0, 0
a = 0, 0, 0, 0, 0, 0, 0, 0
d = 0, 1, 1, 2, 2, 2, 0, 0
op = 2, 2, 2, 3, 3, 3, 1, 2
Current Parameter Setting Default Sent To ESC Options
**Acknowledged**
0)>Brake <= Off Off Off Off, On
1) Battery Type = LiPo NiMH LiPo LiPo, NiMH
2) Cutoff Type = Soft-Cut Cut-Off Soft-Cut Soft-Cut, Cut-Off
3) Cutoff Voltage = Low High Low Low, Middle, High
4) Start Mode = Normal Very Soft Normal Normal, Soft, Very Soft
5) Timing Mode = Low High Low Low, Middle, High
6) "Music" = (not used) (not used) (not used) (not used)
7) Governor Mode = Off Off Off Off, On
When brake is on, the ESC will force the motor to slow down. When
is off the motor will coast.
Enter the parameter number you wish to edit.
Press "<" or ">" to select parameter setting.
The keys "a", "s", d"and "w" may also be used to select parameter and setting.
Press "h" for more information about using this program.
Press "t" to transmit these parameters to the ESC.
Press "L" to load default parameters into active array.
Press "r" to to use received parameters.
Press "x" to exit.
The data displayed after the ESC is read has been increased. I wasn't shifting the bits correctly so I kept adding debug statements until I found the error.
Here's an example terminal window after a read.
bufferIndex = 16
lowest index with zero = 16
bufferIndex and return value from DeltaFromTotal are equal.
Pulses (in milliseconds)
[0] 2.537, 2.530, 5.080, 5.077, 2.532, 2.530, 2.532, 2.530, 2.532, 2.568
[10] 2.532, 2.530, 5.080, 2.530, 15.193, 7.162,
Parsing the time into data.
ParseTimes
Finding the bit values from pulse times.
16 pulses were received.
Time expected for each bit = 2.500 ms *** Default Bit Width ***
First pulse low
1 low bits, raw packet with new bits = %0
1 high bits, raw packet with new bits = %01
No bit timing errors detected.
The new expected time is the average pulse length of the first two bits/pulses.
Time expected for each bit = 2.533 ms
2 low bits, raw packet with new bits = %0100
2 high bits, raw packet with new bits = %01_0011
1 low bits, raw packet with new bits = %010_0110
1 high bits, raw packet with new bits = %0100_1101
1 low bits, raw packet with new bits = %0_1001_1010
1 high bits, raw packet with new bits = %01_0011_0101
1 low bits, raw packet with new bits = %010_0110_1010
1 high bits, raw packet with new bits = %0100_1101_0101
1 low bits, raw packet with new bits = %0_1001_1010_1010
1 high bits, raw packet with new bits = %01_0011_0101_0101
2 low bits, raw packet with new bits = %0100_1101_0101_0100
1 high bits, raw packet with new bits = %0_1001_1010_1010_1001
6 low bits, raw packet with new bits = %010_0110_1010_1010_0100_0000
3 high bits, raw packet with new bits = %01_0011_0101_0101_0010_0000_0111
Shift right 5 bits
totalBitIndex = 26
initial 21 bits to keep = %0_1001_1010_1010_1001_0000
sizingMask[8] = %00_0000_1111_1111
top 8 data bits = %00_0000_0110_1010
top 8 data bits moved back in place = %01_1010_1000_0000
bottom 6 data bits = %00_0000_0001_0000
bottom 6 bits with the top 8 bits = %01_1010_1001_0000
14 bits with order reversed = %00_0010_0101_0110
rawRxPacket = %01_1010_1001_0000
rxPacket = %00_0010_0101_0110
The last lines of the output show the bits getting shifted so only the 14 data bits are retained from the initial 26 bits captured.
The main choices are "c" to read the data from the ESC (aka Confirm data). The key "t" will Transmit the currently selected options to the ESC.
The program no longer automatically attempts to read from the ESC on start up. The program waits for input prior to transmitting data or reading data.
As I said, I think this is a functional program (though very cluttered). I haven't tested it enough to be confident it works correctly. Once it's been tested a bit more, I'll clean up the display.
@Ken, any requests on what you're like to see changed? More channels? Control other than through a terminal window?
I haven't paid much attention to the default settings. I'll look back through the thread and find which settings to use as defaults.
I think that's it for today.
Edit(3/11/15): Warning, the code attached is an old version. There are likely better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't code similar to what is attached here on my on GitHub, send me a message and I'll make and check for any improved versions of the code.
Ouch! That kind of sucks. Got to wonder how the motors kept running with the throttle cut, unless somehow the control went haywire. Maybe you accidentally hit a radio switch in the heat of the moment? I've crashed a number of times and have always been able to cut the throttle before impact.
How did you get the props stopped? Pulling power around spinning props wouldn't be fun either.
Surely you have broken props? Hopefully no bent motor shafts.
I did have one equipment failure, one ESC went belly-up. Of course it resulted in an instant flip and subsequent crash. In that case also the throttle continued to work fine. (not that it did a lot of good )
I'll bet your 10 minutes were fun. Hope you find the source of the problem and get back in the air soon.
-Russ
No broken Props, I was in the high grass. My helicopter training, told me to do this.
BTW I found the problem with the non-responsive throttle. When the Quad flipped, it knocked the crystal out of the receiver. (I'm still using 72 MHz equipment.) The transmitter was transmittin' , but nobody was listening. Yes, I had to reach in and pull the power.
They can all be done at the same time and it is probably a good idea to do it that way to ensure everybody is set identically. To initiate throttle range, the throttle should be set full when energizing the ESC. It will recognize this and chirp out a different pattern (I can never remember exactly what they are). You then set the throttle to min within 2 sec's and you'll get a confirmation beep. Then all is set.
Not sure you could do this with the Hoverfly board since it has to be armed first. That would prevent you from having the throttle in the max position at startup.
I'm trying to think of a scenario to does this, but I can't come up with anything right now.
Not sure you could do this with the Hoverfly board since it has to be armed first. That would prevent you from having the throttle in the max position at startup.
I had to go back to see what you were quoting. Somehow I had missed Russ' earlier comment about setting throttle ranges.
There wouldn't be need to arm the HoverFly board. The firmware on the HoverFly board would be overwritten (only in RAM) by the calibration program. Once the calibration was done the HoverFly board would be turned off and back on to let the normal firmware take effect.
The program could sense if a receiver were connected and it would use the receiver's throttle position as one end point in the throttle range. The user would be instructed to lower the throttle to complete the throttle range setting (I'm not sure if I'm remembering the procedure correctly). The idea is to set the throttle range on all the ESC at the same time (and of course with the same settings).
I had to go back to see what you were quoting. Somehow I had missed Russ' earlier comment about setting throttle ranges.
There wouldn't be need to arm the HoverFly board. The firmware on the HoverFly board would be overwritten (only in RAM) by the calibration program. Once the calibration was done the HoverFly board would be turned off and back on to let the normal firmware take effect.
The program could sense if a receiver were connected and it would use the receiver's throttle position as one end point in the throttle range. The user would be instructed to lower the throttle to complete the throttle range setting (I'm not sure if I'm remembering the procedure correctly). The idea is to set the throttle range on all the ESC at the same time (and of course with the same settings).
OK, that makes sense. I thought we we talking about calibration with the Hoverfly firmware in place.
I've trying to figure out the fastest way of make this program useful to yourself and Daelin. I'm thinking the easiest way this program could help would be to make a single ESC programmer. I'll modify the code to continually monitors the line for incoming pulses. Once a pulse is detected the program will automatically reprogram the board if the settings don't match the default setting.
Two LEDs will indicate the state of the ESC. To indicate no connection, both LEDs will be off. When data is received from the ESC but it doesn't match the default setting, the left LED will turn on after this incorrect data is received the program will automatically send the new settings. Once the new settings are in place the right LED will blink. If the correct setting are received the right LED will be lit solid for a few seconds. I'm thinking of using the LEDs on P23 (left) and P(16) right of the QuickStart board.
This should speed the programming up a bit by not needing to cycle through the buttons on the programming card.
OK, that makes sense. I thought we we talking about calibration with the Hoverfly firmware in place.
Yes, we are - the firmware is there - no software change required. It appears that the firmware detects the full throttle and therefore knows that you are in calibration mode and then passes that throttle setting on to all of the ESC's at once - allowing ranging to be done.
With Jason Dorie's code it is a little different, you set a constant value 'ThrottleStartupTime' and load that into ram. That value is then checked on startup and it SETS the value to send to the ESC's at 2ms:
' Initialize servo values to all neutral (zero for throttles)
' Delay values of 1500 = center, 1000 = min, 2000 = max
if( ThrottleStartupTime == 0 )
'Motors off on startup
Output[0] := Output[1] := Output[2] := Output[3] := 1000
Output[4] := Output[5] := Output[6] := Output[7] := 1000
else
'Motors to full throttle on startup for range setting NOTE: Not all radios output this range
Output[0] := Output[1] := Output[2] := Output[3] := 2000
Output[4] := Output[5] := Output[6] := Output[7] := 2000
I think I may have added the comment about not all systems using 2000 microseconds.
This is in the DAT section:
ThrottleStartupTime long $0 'Hold time in mSec (0 = no throttle range set on startup) 500ms = $1F4
So what I do (for Hoverfly firmware) is turn off my radio alarm for 'not zero throttle at startup'
Go to full throttle
Powerup the quad
Wait for the beeps
Go to zero throttle
Done.....
Not sure if a power cycle is required here or not (I think you can just enable at this point and fly.....).
I don't believe any settings are stored by the Hoverfly firmware, it simply passes thru the signal until the ESC setting is finished.
I just received the following error using version 140804f.
Expected acknowledgment from ESC to equal 1365, but instead it was 1237.
One possible source of trouble is I don't use the new method of extracting bits from pulse times for the acknowledgment. The portion of code which received the acknowledgment assumes 2.5ms per pulse.
I had planned to use the pulse timing technique to capture the acknowledgment anyway so I'll make this change first. If I still get the error, I'll break out the logic analyzer. I may still have an issue with which bits I use for which parameters. My last couple of "transmits" haven't matched what is received back.
Yes, we are - the firmware is there - no software change required. It appears that the firmware detects the full throttle and therefore knows that you are in calibration mode and then passes that throttle setting on to all of the ESC's at once - allowing ranging to be done.
Russ,
I don't know how I missed that. Hoverfly thought of everything!
The acknowledgment bits are now read in with the same pulse timing technique as the data is read from the ESC. Hopefully this is the end of the timing issues.
Most of the debug statements have been turned off. Many of these statements can be turned back on my entering the "extra debug mode". The character "e" (lowercase only) will toggle between the extra debug mode and normal mode.
If you do find an error hopefully you'll be able to repeat with the extra debug statements in order to help diagnose the problem.
I'll try to get the version to automatically start programming the ESC with LED indicators working.
Edit(3/11/15): Warning, the code attached is an old version. There are likely better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't code similar to what is attached here on my on GitHub, send me a message and I'll make and check for any improved versions of the code.
The acknowledgment bits are now read in with the same pulse timing technique as the data is read from the ESC. Hopefully this is the end of the timing issues.
Most of the debug statements have been turned off. Many of these statements can be turned back on my entering the "extra debug mode". The character "e" (lowercase only) will toggle between the extra debug mode and normal mode.
If you do find an error hopefully you'll be able to repeat with the extra debug statements in order to help diagnose the problem.
I'll try to get the version to automatically start programming the ESC with LED indicators working.
Would love to try it, the Quad crashed again. Went trough all calibrations, new firmware update. The thing would pulsate,(throttle up-then down) on the ground at full throttle for 5-6 seconds, then take off , without much control. Gear was off.
I'll have to start a new thread on this one. I broke a prop so I'm dead in the water now.
Would love to try it, the Quad crashed again. Went trough all calibrations, new firmware update. The thing would pulsate,(throttle up-then down) on the ground at full throttle for 5-6 seconds, then take off , without much control. Gear was off.
I'll have to start a new thread on this one. I broke a prop so I'm dead in the water now.
Jim
Surely you bought a crash kit. ;-) I have a new set of Carbon Fiber props that are still in the packaging and probably 4 each of the standard-issue style - you just never know.
While contemplating making changes to Jason Dorie's code, my worst fear was losing complete control of the helicopter due to some weird logic error. I mean, on a fresh battery, that thing could go extremely high or far or both.
I would consider strapping it down and trying to debug whatever issue is making it behave so weird.
Once again, I think I have a fixed program.
Please let me know if you find any issue.
Using Propeller Quickstart, with pin 28 (SDA) connected to ESC line. 'c' option cannot read from ESC. I get a 'Timeout While High'. Tried a 10k pullup to Vdd (3.3V) on that line - same result.
Using Propeller Quickstart, with pin 28 (SDA) connected to ESC line. 'c' option cannot read from ESC. I get a 'Timeout While High'. Tried a 10k pullup to Vdd (3.3V) on that line - same result.
Am I wired correctly?
-Russ
Pin 28 is SCL. Pin 29 is SDA. On the QuickStart these pins are located opposite of what one would expect. Pin 28 is position 31 and Pin 29 is position 29 (maybe that's why the switched them so P29 is pin #29 on the header?).
Can you transmit settings and get an acknowledgment?
To receive data, you need to press the key when instructed and power on the ESC (it can either be off and powered on or the power can be cycled).
I thought I had a version which would behave a lot like the programming card except it would automatically send the default settings if the settings on the ESC weren't correct. It would save the time of pushing the buttons on the card and probably cut the time to program in half.
I tested the code several times (I even have a witness) and it worked great. I cleaned up the code (I was sure I didn't change anything functional but I may be wrong) and moved into to the other room to make a video of it in action. Once I tried to get it to work "on film" the Propeller refused to perform correctly.
I'll get this figured out in the morning.
Russ, is it still not working?
I found it's a bad idea to connect the signal line to one of the I2C pins if you want to power the Propeller from the BEC on the ESC. The I2C activity as the Propeller boots up confuses the ESC as it first turns on.
From what I can tell, the code attached to post #104 should work. As it is now using a Propeller to program an ESC isn't any faster than a programming card but I intend to change that (in the morning).
Hi all,
After testing and way too much research, it is my opinion that the best "default" settings for the ELEV-8 v2 are as follows:
Brake: OFF
Battery Type*: Li-xx
Cut Off Type: Soft-Cut
Cut Off Voltage*: Middle
Start Mode: Normal
Timing Mode**: Middle
Music/LiPo Cells: blank (no , auto detection of LiPo cell #s)
Governor Mode: Off
Unless I hear otherwise, I'm going to use the above settings for the default settings in future version of the code.
The default settings used in the code attached to post #104 were selected to aid in recognizing the traces with the logic analyzer. They would not make good settings for a quadcopter.
I have some little 6 amp ESCs which I was attempting to use with this program and I found the bit width of these little ESC is 2.0ms. I had thought 2.4ms would an extremely low bit width.
This won't require any major changes. I just need to adjust the maximum and minimum values allowed to be considered a valid bit.
The code I had previously posted didn't read from the small 6A ESCs correctly even after I adjusted the minimum allowed bit time to 1.8ms.
I had a bug in the program which wasn't noticeable until it was used with an ESC with severely different timing than a 2.5ms bit length. While the program was dutifully calculating a new "singleBitTime" after the first two bits were received, the portion of the program calculating the number of bits in a pulse was using the constant value "BIT_TIME_WIDTH" which is set to 2.5ms.
The difference between 2.0ms and 2.5ms is enough to cause confusion with just four bits. The previous default settings produced an alternating bit pattern with no more than two consecutive bits. This is why my program to automatically start reading from the card on power up worked with the old default settings but not with the new settings (which has four zeros in a row).
I've attached the fixed version of the code (I feel like I'm repeating myself).
I want to tweak some of the delays used by the code intended to be used for quick programming of preset values before I post it. I'll try to get this other version posted soon.
Edit: This version of code uses a menu to set the ESC parameters.
I'm sure Duane will let me know when he's ready to turn this over to us.
I think I have something useful now.
This attached version doesn't send data to a terminal window. It used LEDs (like the ones on a QuickStart) to display its status.
Here's a one handed video of the QuickStart ESC programmer in action.
Like the programming card, it's powered by the ESC's BEC. It should be faster to program ESCs with a QuickStart than with a programming card since the settings are programmed into the Propeller and there's no need to scroll through the buttons/LEDs as one does with the programming card.
As I say in the video, when the four LEDs on the right side of the QuickStart are lit, it means the ESC sent a proper acknowledgment. There really isn't a need to read the settings back from the ESC. If the settings in the ESC match the default settings in the Propeller, all 8 LEDs are turned on to so the ESC is already properly programmed. So either 4 right LEDs lit or all 8 LEDs lit means the ESC should be properly programmed.
The I2C lines can not be used with this setup. The initial I2C communication interferes with the ESC's ability to send data.
I used P26 as the communication line. I didn't add a pull-up resistor but when I attached logic analyzer clips, I had to add a pull-up in order to get a good signal. Normally one wouldn't need a pull-up on the line. At least I don't need a pull-up with the ESCs I've tested. I've learned ESCs can vary a lot so some ESCs may require a pull-up in order to communicate with the Propeller.
Edit: This version of code does not have a menu. It will just start its programming sequence as soon as it is powered on.
Tried 140805e.spin again. The signal line of the ESC was connected to the SCL pin (as far as I can tell) and a 10k pullup connected to VDD. With the ESC unpowered the signal line was at 2.2V, when powered up the voltage goes to about 3.4V.
My Quickstart board is a rev A and here's the pin I connected to:
I tried leaving the ESC off, running the program and then powering up the ESC. I also tried powering up both the ESC and propeller and cycling power on the ESC when prompted. Neither was successful at reading the ESC. This is the error:
At one time I got a 'successful' read, but it looks like some values are garbled:
I get the feeling I'm doing something wrong, but I'm not sure what it may be. The setup works fine with the Turnigy programming card.
I don't know if version 140806a would have worked any better in this case or not but I'm hoping to talk you into trying it.
The "garbled" output looks like the program was attempting to read from a signal line held high except for a bit of noise which caused the program to think it had received a transmission.
When you try version 140806a, use a pin without a pull-up. In version 140806a the pin is set to P26. Hopefully this will work.
Along with trying version 140806a, I'm hoping you'll also try "EscSimpleAutoProgrammer140806c" attached to post #114. Use F11 to load "EscSimpleAutoProgrammer140806c" to EEPROM and then disconnect the USB from the QuickStart. With "EscSimpleAutoProgrammer140806c" loaded, you'll then power the QuickStart from the ESC's BEC. Connect the signal line to P26, the center power line (5V) connects to VIN (pin 40 of the header) and the ground line connects with the ground on the QuickStart on pin # 39 of the header.
With the program "EscSimpleAutoProgrammer140806c" loaded into the QuickStart's EEPROM, you should be able to get similar results to those shown in post #14.
I've seen there's a lot of variation among ESCs. It really helps to get feedback from others about how the program is works on their particular ESC.
I got three different results. One, was 1100 0000. The other was 1100 0000 -> 1111 0000 -> 0000 1010. And lastly, 1100 0000 -> 1111 0000 -> 0000 1111.
. . .
I was getting the 1st result everytime, until I plugged in the Turnigy card. After that, I got the 2nd result and then the 3rd.
Are you powering the QuickStart from the ESC?
I can't figure out why you'd be getting those results.
When the program first come on it should display the two left LEDs.
Wait for initial read: 1100_0000
If it gets a good reading then: 1110_0000
A timeout would result in: 0010_0000
This 0010_0000 pattern is what I'd get when I had something setup incorrectly. This is one possible end of the program.
The program only continues if it was able to read from the ESC. My guess is your ESC needs a pull up for the program to communicate with it but I'd expect all your attempts to end with 0010_0000 displayed on the LEDs.
Result #2 is also strange since it indicates the acknowledgement was incorrect but then the program should continue to attempt to write to the ESC until it received the correct acknowledgment.
Result #3 indicates the ESC sent the correct acknowledgment and if you made one more attempt, you should see the 1111_1111 pattern indicating the ESC was programmed correctly.
I'd hope a pull-resistor on the signal line would clear things up. You can't use the I2C pins with the "EscSimpleAutoProgrammer" version since the Propeller needs to read the EEPROM during boot up and the pulses on the line from the EEPROM read will interfere with the ESC (at least it did with mine).
I think adding the programming card to the circuit added a pull-up to the line but the programming card may also be interfering with the Prop to ESC communication.
I don't suppose you tried it without the motors connected? I haven't tried any of these with a motor attached to the ESC.
What else was connected to the QuickStart? I see two wires on the Vdd and Vss header. What are those connected to?
Thanks for trying this. I'm guessing there are some ESCs which require pull up resistors on the line. As I mentioned in an earlier post, if I attach the logic analyzer probes to the signal line, I have to use a pull up on the line or I keep getting the 0010_0000 error.
Regarding the programming card, it wasn't added to the circuit. I disconnected the Quickstart, connected the programming card, made a change (to music), disconnected the card and then reconnected the Quickstart. I powered down between connections. I was concerned that maybe the ESC wasn't working correctly so had connected the programming card just to make sure. I also connected a servo tester and ran the motor as a test. It was after the those tests that the Quickstart results changed.
The added lines were going to a multimeter monitoring the 3.3V on the board.
I also tried without the motor connected with the same results.
If you thought it would be helpful I could send you the ESC.
I can't figure out why you'd be getting those results.
When the program first come on it should display the two left LEDs.
Wait for initial read: 1100_0000
If it gets a good reading then: 1110_0000
A timeout would result in: 0010_0000
This 0010_0000 pattern is what I'd get when I had something setup incorrectly. This is one possible end of the program.
The program only continues if it was able to read from the ESC. My guess is your ESC needs a pull up for the program to communicate with it but I'd expect all your attempts to end with 0010_0000 displayed on the LEDs.
Result #2 is also strange since it indicates the acknowledgement was incorrect but then the program should continue to attempt to write to the ESC until it received the correct acknowledgment.
Result #3 indicates the ESC sent the correct acknowledgment and if you made one more attempt, you should see the 1111_1111 pattern indicating the ESC was programmed correctly.
I'd hope a pull-resistor on the signal line would clear things up. You can't use the I2C pins with the "EscSimpleAutoProgrammer" version since the Propeller needs to read the EEPROM during boot up and the pulses on the line from the EEPROM read will interfere with the ESC (at least it did with mine).
I think adding the programming card to the circuit added a pull-up to the line but the programming card may also be interfering with the Prop to ESC communication.
I don't suppose you tried it without the motors connected? I haven't tried any of these with a motor attached to the ESC.
What else was connected to the QuickStart? I see two wires on the Vdd and Vss header. What are those connected to?
Thanks for trying this. I'm guessing there are some ESCs which require pull up resistors on the line. As I mentioned in an earlier post, if I attach the logic analyzer probes to the signal line, I have to use a pull up on the line or I keep getting the 0010_0000 error.
I'm very curious to see how the ESC behaves with a pull-up resitor on the signal line.
Here are a couple of pictures of my method of adding a pull-up on pin 26.
If a pull-up doesn't solve the communication problem then you could also try changing the value of the constant "STARTUP_ESC_HIGH_TIME" on line 98.
STARTUP_ESC_HIGH_TIME = 100 * MILLISECOND ' 1_500
I lowered this value to 100ms since it takes a while after power is connected for the system clock to get up and running. With the original 1,500ms delay, the program was missing the initial message from the ESC. I suppose some ESC may need the value of "STARTUP_ESC_HIGH_TIME" reduced even more. You could try 20ms or even less.
If you thought it would be helpful I could send you the ESC.
If using a pull-up resistor and changing the start up time doesn't get it to work, it could be useful to take a look at the ESC with my logic analyzer. I might take you up on your offer to loan your ESC.
Ken mentioned in an email the program was working with their ESCs. It's strange your ESC doesn't behave the same as the Parallax ESCs. I thought you purchased yours from Parallax?
Thanks for testing out the program. I would like to get these programs to work with all ESC capable of being programmed with the Turnigy programming card.
How does you ESC behave when using the program attached to post #113. If you get strange results, use "e" to turn on extra debugging information. The extra debugging information may let us know what the problem is if you have trouble with that program too.
You can copy and paste from the debug window to a forum "code" box. Sometimes you have to press control-C more than once to get the text to copy.
Thanks for the extra information.
I'm very curious to see how the ESC behaves with a pull-up resitor on the signal line.
Success! The "EscSimpleAutoProgrammer" works fine with a pull-up. I think I know now why the pull-up was ineffective in my earlier tests. I'm using a 1/8W 10k resistor. These have a very fine lead. I had not noticed that neither the breadboard I was using or the header on Quickstart could make a good connection. Today I used alligator-clip test leads and that did the trick!
I'll try the ESC Complicated Manual Programmer now.
ESC-Programmer140806a.spin also works with the pull-up in place.
Comments
I hope to have code to post later today but for now I wanted to show the results of my code to read the bits from the time intervals.
Hopefully this output will let you see what the code is doing.
Pulses (in milliseconds) [0] 2.537, 2.530, 5.041, 5.077, 2.532, 2.530, 2.532, 2.530, 2.532, 2.568 [10] 2.532, 2.530, 5.041, 2.530, 15.231, 7.200, Parsing the time into data. ParseTimes Finding the bit values from pulse times. 16 pulses were received. Time expected for each bit = 2.500 ms *** Default Bit Width *** First pulse low 1 low bits, raw packet with new bits = %0 1 high bits, raw packet with new bits = %01 No bit timing errors detected. The new expected time is the average pulse length of the first two bits/pulses. Time expected for each bit = 2.533 ms 2 low bits, raw packet with new bits = %0100 2 high bits, raw packet with new bits = %01_0011 1 low bits, raw packet with new bits = %010_0110 1 high bits, raw packet with new bits = %0100_1101 1 low bits, raw packet with new bits = %0_1001_1010 1 high bits, raw packet with new bits = %01_0011_0101 1 low bits, raw packet with new bits = %010_0110_1010 1 high bits, raw packet with new bits = %0100_1101_0101 1 low bits, raw packet with new bits = %0_1001_1010_1010 1 high bits, raw packet with new bits = %01_0011_0101_0101 2 low bits, raw packet with new bits = %0100_1101_0101_0100 1 high bits, raw packet with new bits = %0_1001_1010_1010_1001 6 low bits, raw packet with new bits = %010_0110_1010_1010_0100_0000 3 high bits, raw packet with new bits = %01_0011_0101_0101_0010_0000_0111 rawRxPacket = %00_1001_1000_0111 rxPacket = %11_1000_0110_0100The program uses the first two bits received to reset the bit timing. This timing reset isn't really needed since timing errors no longer accumulate. Each high or low pulse is parsed into the bits one pulse at a time (after all the pulses have been captured).
Anyway, I think it's kind of a cool way to capture bits.
As I said, I hope to post some code later today.
Took my first flight last night with hover training as usual. Was fine for 10 minutes, then the copter went crazy and headed for my unprotected leg, (wearing shorts, those props are sharp!).
The unit ended up upside down with the props spinning, even thought the throttle was cut to 0.
Going to leave it together to show at the expo, and then tear it down and do all the calibrations again, along with the ECS throttle calibration.
How did you get the props stopped? Pulling power around spinning props wouldn't be fun either.
Surely you have broken props? Hopefully no bent motor shafts.
I did have one equipment failure, one ESC went belly-up. Of course it resulted in an instant flip and subsequent crash. In that case also the throttle continued to work fine. (not that it did a lot of good
I'll bet your 10 minutes were fun.
-Russ
This version has a lot of debug statements. I'll clean them out after the code as been tested a bit. If any of you can find bugs, it would help if you would also cut and paste what's displayed in the terminal window and post it with the bug report.
The timing differences between ESCs shouldn't be a problem anymore.
What was previously the "From ESC" will still display the data read from the ESC unless data had been transmitted since the last time data had been read. If the last data exchange was sending data then the column contains the settings last "Sent To ESC".
Here's a sample screen:
BuildParameterWord txPacket = %00_0000_0000_0000 current selection = %00_0000_0000_0000 rxPacket = %00_0010_1101_0111 The current parameter settings match the settings transmitted to the ESC. You should not need to transmit parameters unless a change is made to the current settings. programName = ESC-Programmer140804f par# 0 1 2 3 4 5 6 7 rx = 1, 1, 1, 2, 2, 2, 0, 1 tx = 0, 0, 0, 0, 0, 0, 0, 0 a = 0, 0, 0, 0, 0, 0, 0, 0 d = 0, 1, 1, 2, 2, 2, 0, 0 op = 2, 2, 2, 3, 3, 3, 1, 2 Current Parameter Setting Default Sent To ESC Options **Acknowledged** 0)>Brake <= Off Off Off Off, On 1) Battery Type = LiPo NiMH LiPo LiPo, NiMH 2) Cutoff Type = Soft-Cut Cut-Off Soft-Cut Soft-Cut, Cut-Off 3) Cutoff Voltage = Low High Low Low, Middle, High 4) Start Mode = Normal Very Soft Normal Normal, Soft, Very Soft 5) Timing Mode = Low High Low Low, Middle, High 6) "Music" = (not used) (not used) (not used) (not used) 7) Governor Mode = Off Off Off Off, On When brake is on, the ESC will force the motor to slow down. When is off the motor will coast. Enter the parameter number you wish to edit. Press "<" or ">" to select parameter setting. The keys "a", "s", d"and "w" may also be used to select parameter and setting. Press "h" for more information about using this program. Press "t" to transmit these parameters to the ESC. Press "L" to load default parameters into active array. Press "r" to to use received parameters. Press "x" to exit.The data displayed after the ESC is read has been increased. I wasn't shifting the bits correctly so I kept adding debug statements until I found the error.
Here's an example terminal window after a read.
bufferIndex = 16 lowest index with zero = 16 bufferIndex and return value from DeltaFromTotal are equal. Pulses (in milliseconds) [0] 2.537, 2.530, 5.080, 5.077, 2.532, 2.530, 2.532, 2.530, 2.532, 2.568 [10] 2.532, 2.530, 5.080, 2.530, 15.193, 7.162, Parsing the time into data. ParseTimes Finding the bit values from pulse times. 16 pulses were received. Time expected for each bit = 2.500 ms *** Default Bit Width *** First pulse low 1 low bits, raw packet with new bits = %0 1 high bits, raw packet with new bits = %01 No bit timing errors detected. The new expected time is the average pulse length of the first two bits/pulses. Time expected for each bit = 2.533 ms 2 low bits, raw packet with new bits = %0100 2 high bits, raw packet with new bits = %01_0011 1 low bits, raw packet with new bits = %010_0110 1 high bits, raw packet with new bits = %0100_1101 1 low bits, raw packet with new bits = %0_1001_1010 1 high bits, raw packet with new bits = %01_0011_0101 1 low bits, raw packet with new bits = %010_0110_1010 1 high bits, raw packet with new bits = %0100_1101_0101 1 low bits, raw packet with new bits = %0_1001_1010_1010 1 high bits, raw packet with new bits = %01_0011_0101_0101 2 low bits, raw packet with new bits = %0100_1101_0101_0100 1 high bits, raw packet with new bits = %0_1001_1010_1010_1001 6 low bits, raw packet with new bits = %010_0110_1010_1010_0100_0000 3 high bits, raw packet with new bits = %01_0011_0101_0101_0010_0000_0111 Shift right 5 bits totalBitIndex = 26 initial 21 bits to keep = %0_1001_1010_1010_1001_0000 sizingMask[8] = %00_0000_1111_1111 top 8 data bits = %00_0000_0110_1010 top 8 data bits moved back in place = %01_1010_1000_0000 bottom 6 data bits = %00_0000_0001_0000 bottom 6 bits with the top 8 bits = %01_1010_1001_0000 14 bits with order reversed = %00_0010_0101_0110 rawRxPacket = %01_1010_1001_0000 rxPacket = %00_0010_0101_0110The last lines of the output show the bits getting shifted so only the 14 data bits are retained from the initial 26 bits captured.
The main choices are "c" to read the data from the ESC (aka Confirm data). The key "t" will Transmit the currently selected options to the ESC.
The program no longer automatically attempts to read from the ESC on start up. The program waits for input prior to transmitting data or reading data.
As I said, I think this is a functional program (though very cluttered). I haven't tested it enough to be confident it works correctly. Once it's been tested a bit more, I'll clean up the display.
@Ken, any requests on what you're like to see changed? More channels? Control other than through a terminal window?
I haven't paid much attention to the default settings. I'll look back through the thread and find which settings to use as defaults.
I think that's it for today.
Edit(3/11/15): Warning, the code attached is an old version. There are likely better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't code similar to what is attached here on my on GitHub, send me a message and I'll make and check for any improved versions of the code.
No broken Props, I was in the high grass. My helicopter training, told me to do this.
BTW I found the problem with the non-responsive throttle. When the Quad flipped, it knocked the crystal out of the receiver. (I'm still using 72 MHz equipment.) The transmitter was transmittin' , but nobody was listening.
Jim
Not sure you could do this with the Hoverfly board since it has to be armed first. That would prevent you from having the throttle in the max position at startup.
I'm trying to think of a scenario to does this, but I can't come up with anything right now.
I had to go back to see what you were quoting. Somehow I had missed Russ' earlier comment about setting throttle ranges.
There wouldn't be need to arm the HoverFly board. The firmware on the HoverFly board would be overwritten (only in RAM) by the calibration program. Once the calibration was done the HoverFly board would be turned off and back on to let the normal firmware take effect.
The program could sense if a receiver were connected and it would use the receiver's throttle position as one end point in the throttle range. The user would be instructed to lower the throttle to complete the throttle range setting (I'm not sure if I'm remembering the procedure correctly). The idea is to set the throttle range on all the ESC at the same time (and of course with the same settings).
OK, that makes sense. I thought we we talking about calibration with the Hoverfly firmware in place.
I've trying to figure out the fastest way of make this program useful to yourself and Daelin. I'm thinking the easiest way this program could help would be to make a single ESC programmer. I'll modify the code to continually monitors the line for incoming pulses. Once a pulse is detected the program will automatically reprogram the board if the settings don't match the default setting.
Two LEDs will indicate the state of the ESC. To indicate no connection, both LEDs will be off. When data is received from the ESC but it doesn't match the default setting, the left LED will turn on after this incorrect data is received the program will automatically send the new settings. Once the new settings are in place the right LED will blink. If the correct setting are received the right LED will be lit solid for a few seconds. I'm thinking of using the LEDs on P23 (left) and P(16) right of the QuickStart board.
This should speed the programming up a bit by not needing to cycle through the buttons on the programming card.
Yes, we are - the firmware is there - no software change required. It appears that the firmware detects the full throttle and therefore knows that you are in calibration mode and then passes that throttle setting on to all of the ESC's at once - allowing ranging to be done.
With Jason Dorie's code it is a little different, you set a constant value 'ThrottleStartupTime' and load that into ram. That value is then checked on startup and it SETS the value to send to the ESC's at 2ms:
' Initialize servo values to all neutral (zero for throttles) ' Delay values of 1500 = center, 1000 = min, 2000 = max if( ThrottleStartupTime == 0 ) 'Motors off on startup Output[0] := Output[1] := Output[2] := Output[3] := 1000 Output[4] := Output[5] := Output[6] := Output[7] := 1000 else 'Motors to full throttle on startup for range setting NOTE: Not all radios output this range Output[0] := Output[1] := Output[2] := Output[3] := 2000 Output[4] := Output[5] := Output[6] := Output[7] := 2000I think I may have added the comment about not all systems using 2000 microseconds.
This is in the DAT section:
So what I do (for Hoverfly firmware) is turn off my radio alarm for 'not zero throttle at startup'
Go to full throttle
Powerup the quad
Wait for the beeps
Go to zero throttle
Done.....
Not sure if a power cycle is required here or not (I think you can just enable at this point and fly.....).
I don't believe any settings are stored by the Hoverfly firmware, it simply passes thru the signal until the ESC setting is finished.
-Russ
And once again, I'm wrong.
I just received the following error using version 140804f.
One possible source of trouble is I don't use the new method of extracting bits from pulse times for the acknowledgment. The portion of code which received the acknowledgment assumes 2.5ms per pulse.
I had planned to use the pulse timing technique to capture the acknowledgment anyway so I'll make this change first. If I still get the error, I'll break out the logic analyzer. I may still have an issue with which bits I use for which parameters. My last couple of "transmits" haven't matched what is received back.
So for now, the code is not reliable.
Russ,
I don't know how I missed that. Hoverfly thought of everything!
I'm back flying again!
Jim
Please let me know if you find any issue.
The acknowledgment bits are now read in with the same pulse timing technique as the data is read from the ESC. Hopefully this is the end of the timing issues.
Most of the debug statements have been turned off. Many of these statements can be turned back on my entering the "extra debug mode". The character "e" (lowercase only) will toggle between the extra debug mode and normal mode.
If you do find an error hopefully you'll be able to repeat with the extra debug statements in order to help diagnose the problem.
I'll try to get the version to automatically start programming the ESC with LED indicators working.
Edit(3/11/15): Warning, the code attached is an old version. There are likely better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't code similar to what is attached here on my on GitHub, send me a message and I'll make and check for any improved versions of the code.
Would love to try it, the Quad crashed again. Went trough all calibrations, new firmware update. The thing would pulsate,(throttle up-then down) on the ground at full throttle for 5-6 seconds, then take off , without much control. Gear was off.
I'll have to start a new thread on this one. I broke a prop so I'm dead in the water now.
Jim
Surely you bought a crash kit. ;-) I have a new set of Carbon Fiber props that are still in the packaging and probably 4 each of the standard-issue style - you just never know.
While contemplating making changes to Jason Dorie's code, my worst fear was losing complete control of the helicopter due to some weird logic error. I mean, on a fresh battery, that thing could go extremely high or far or both.
I would consider strapping it down and trying to debug whatever issue is making it behave so weird.
-Russ
Using Propeller Quickstart, with pin 28 (SDA) connected to ESC line. 'c' option cannot read from ESC. I get a 'Timeout While High'. Tried a 10k pullup to Vdd (3.3V) on that line - same result.
Am I wired correctly?
-Russ
Pin 28 is SCL. Pin 29 is SDA. On the QuickStart these pins are located opposite of what one would expect. Pin 28 is position 31 and Pin 29 is position 29 (maybe that's why the switched them so P29 is pin #29 on the header?).
Can you transmit settings and get an acknowledgment?
To receive data, you need to press the key when instructed and power on the ESC (it can either be off and powered on or the power can be cycled).
I tested the code several times (I even have a witness) and it worked great. I cleaned up the code (I was sure I didn't change anything functional but I may be wrong) and moved into to the other room to make a video of it in action. Once I tried to get it to work "on film" the Propeller refused to perform correctly.
I'll get this figured out in the morning.
Russ, is it still not working?
I found it's a bad idea to connect the signal line to one of the I2C pins if you want to power the Propeller from the BEC on the ESC. The I2C activity as the Propeller boots up confuses the ESC as it first turns on.
From what I can tell, the code attached to post #104 should work. As it is now using a Propeller to program an ESC isn't any faster than a programming card but I intend to change that (in the morning).
Unless I hear otherwise, I'm going to use the above settings for the default settings in future version of the code.
The default settings used in the code attached to post #104 were selected to aid in recognizing the traces with the logic analyzer. They would not make good settings for a quadcopter.
Haven't yet had a chance to test again. I'll take a look after work - work seems to always get in the way of more interesting things.
-Russ
I have some little 6 amp ESCs which I was attempting to use with this program and I found the bit width of these little ESC is 2.0ms. I had thought 2.4ms would an extremely low bit width.
This won't require any major changes. I just need to adjust the maximum and minimum values allowed to be considered a valid bit.
I had a bug in the program which wasn't noticeable until it was used with an ESC with severely different timing than a 2.5ms bit length. While the program was dutifully calculating a new "singleBitTime" after the first two bits were received, the portion of the program calculating the number of bits in a pulse was using the constant value "BIT_TIME_WIDTH" which is set to 2.5ms.
The difference between 2.0ms and 2.5ms is enough to cause confusion with just four bits. The previous default settings produced an alternating bit pattern with no more than two consecutive bits. This is why my program to automatically start reading from the card on power up worked with the old default settings but not with the new settings (which has four zeros in a row).
I've attached the fixed version of the code (I feel like I'm repeating myself).
I want to tweak some of the delays used by the code intended to be used for quick programming of preset values before I post it. I'll try to get this other version posted soon.
Edit: This version of code uses a menu to set the ESC parameters.
I think I have something useful now.
This attached version doesn't send data to a terminal window. It used LEDs (like the ones on a QuickStart) to display its status.
Here's a one handed video of the QuickStart ESC programmer in action.
Like the programming card, it's powered by the ESC's BEC. It should be faster to program ESCs with a QuickStart than with a programming card since the settings are programmed into the Propeller and there's no need to scroll through the buttons/LEDs as one does with the programming card.
As I say in the video, when the four LEDs on the right side of the QuickStart are lit, it means the ESC sent a proper acknowledgment. There really isn't a need to read the settings back from the ESC. If the settings in the ESC match the default settings in the Propeller, all 8 LEDs are turned on to so the ESC is already properly programmed. So either 4 right LEDs lit or all 8 LEDs lit means the ESC should be properly programmed.
The I2C lines can not be used with this setup. The initial I2C communication interferes with the ESC's ability to send data.
I used P26 as the communication line. I didn't add a pull-up resistor but when I attached logic analyzer clips, I had to add a pull-up in order to get a good signal. Normally one wouldn't need a pull-up on the line. At least I don't need a pull-up with the ESCs I've tested. I've learned ESCs can vary a lot so some ESCs may require a pull-up in order to communicate with the Propeller.
Edit: This version of code does not have a menu. It will just start its programming sequence as soon as it is powered on.
My Quickstart board is a rev A and here's the pin I connected to:
I tried leaving the ESC off, running the program and then powering up the ESC. I also tried powering up both the ESC and propeller and cycling power on the ESC when prompted. Neither was successful at reading the ESC. This is the error:
At one time I got a 'successful' read, but it looks like some values are garbled:
I get the feeling I'm doing something wrong, but I'm not sure what it may be. The setup works fine with the Turnigy programming card.
-Russ
Thank you very much for the feedback Russ.
I don't know if version 140806a would have worked any better in this case or not but I'm hoping to talk you into trying it.
The "garbled" output looks like the program was attempting to read from a signal line held high except for a bit of noise which caused the program to think it had received a transmission.
When you try version 140806a, use a pin without a pull-up. In version 140806a the pin is set to P26. Hopefully this will work.
Along with trying version 140806a, I'm hoping you'll also try "EscSimpleAutoProgrammer140806c" attached to post #114. Use F11 to load "EscSimpleAutoProgrammer140806c" to EEPROM and then disconnect the USB from the QuickStart. With "EscSimpleAutoProgrammer140806c" loaded, you'll then power the QuickStart from the ESC's BEC. Connect the signal line to P26, the center power line (5V) connects to VIN (pin 40 of the header) and the ground line connects with the ground on the QuickStart on pin # 39 of the header.
With the program "EscSimpleAutoProgrammer140806c" loaded into the QuickStart's EEPROM, you should be able to get similar results to those shown in post #14.
I've seen there's a lot of variation among ESCs. It really helps to get feedback from others about how the program is works on their particular ESC.
Again, thanks for the feedback Russ.
I got three different results. One, was 1100 0000. The other was 1100 0000 -> 1111 0000 -> 0000 1010. And lastly, 1100 0000 -> 1111 0000 -> 0000 1111.
Here are clips...
[video=youtube_share;VvsJdnIewag]
[video=youtube_share;nUklTh5Om9U]
[video=youtube_share;-EFsTAZV8M4]
I was getting the 1st result everytime, until I plugged in the Turnigy card. After that, I got the 2nd result and then the 3rd.
-Russ
Are you powering the QuickStart from the ESC?
I can't figure out why you'd be getting those results.
When the program first come on it should display the two left LEDs.
Wait for initial read: 1100_0000
If it gets a good reading then: 1110_0000
A timeout would result in: 0010_0000
This 0010_0000 pattern is what I'd get when I had something setup incorrectly. This is one possible end of the program.
The program only continues if it was able to read from the ESC. My guess is your ESC needs a pull up for the program to communicate with it but I'd expect all your attempts to end with 0010_0000 displayed on the LEDs.
Result #2 is also strange since it indicates the acknowledgement was incorrect but then the program should continue to attempt to write to the ESC until it received the correct acknowledgment.
Result #3 indicates the ESC sent the correct acknowledgment and if you made one more attempt, you should see the 1111_1111 pattern indicating the ESC was programmed correctly.
I'd hope a pull-resistor on the signal line would clear things up. You can't use the I2C pins with the "EscSimpleAutoProgrammer" version since the Propeller needs to read the EEPROM during boot up and the pulses on the line from the EEPROM read will interfere with the ESC (at least it did with mine).
I think adding the programming card to the circuit added a pull-up to the line but the programming card may also be interfering with the Prop to ESC communication.
I don't suppose you tried it without the motors connected? I haven't tried any of these with a motor attached to the ESC.
What else was connected to the QuickStart? I see two wires on the Vdd and Vss header. What are those connected to?
Thanks for trying this. I'm guessing there are some ESCs which require pull up resistors on the line. As I mentioned in an earlier post, if I attach the logic analyzer probes to the signal line, I have to use a pull up on the line or I keep getting the 0010_0000 error.
The added lines were going to a multimeter monitoring the 3.3V on the board.
I also tried without the motor connected with the same results.
If you thought it would be helpful I could send you the ESC.
-Russ
I'm very curious to see how the ESC behaves with a pull-up resitor on the signal line.
Here are a couple of pictures of my method of adding a pull-up on pin 26.
If a pull-up doesn't solve the communication problem then you could also try changing the value of the constant "STARTUP_ESC_HIGH_TIME" on line 98.
I lowered this value to 100ms since it takes a while after power is connected for the system clock to get up and running. With the original 1,500ms delay, the program was missing the initial message from the ESC. I suppose some ESC may need the value of "STARTUP_ESC_HIGH_TIME" reduced even more. You could try 20ms or even less.
If using a pull-up resistor and changing the start up time doesn't get it to work, it could be useful to take a look at the ESC with my logic analyzer. I might take you up on your offer to loan your ESC.
Ken mentioned in an email the program was working with their ESCs. It's strange your ESC doesn't behave the same as the Parallax ESCs. I thought you purchased yours from Parallax?
Thanks for testing out the program. I would like to get these programs to work with all ESC capable of being programmed with the Turnigy programming card.
How does you ESC behave when using the program attached to post #113. If you get strange results, use "e" to turn on extra debugging information. The extra debugging information may let us know what the problem is if you have trouble with that program too.
You can copy and paste from the debug window to a forum "code" box. Sometimes you have to press control-C more than once to get the text to copy.
Success! The "EscSimpleAutoProgrammer" works fine with a pull-up. I think I know now why the pull-up was ineffective in my earlier tests. I'm using a 1/8W 10k resistor. These have a very fine lead. I had not noticed that neither the breadboard I was using or the header on Quickstart could make a good connection. Today I used alligator-clip test leads and that did the trick!
I'll try the ESC Complicated Manual Programmer now.
ESC-Programmer140806a.spin also works with the pull-up in place.
-Russ