I think HoverFly doesn't want the ESCs to decide when to reduce power. IMO, you want to make sure and use an alarm with your 'copter and probably a timer.
HoverFly may have a good point about not wanting the power to be reduced as you're bringing your quad back for a landing.
I plan to add a menu of sorts to the program so the user can select which setting they wish to use.
Earlier I said something about watching to see how the programming card queries the ESC. If I had read what Roy wrote more carefully, I would have seen the programming card doesn't query the ESC at all. The only time the ESC sends data to the card (that I'm aware of) is when the ESC is first powered on.
Roy's code has provisions to read this data. I'll include some sort of instruction for the user to cycle the power on the ESC so the Propeller can make sure the settings "took".
I'm sure these alarms have paid for themselves many times over by warning me of LiPo packs I left connected which would have been ruined if I hadn't had an alarm on them.
Duane, can you hear these from say, 100 yards away?
I'm pretty sure they could be heard 100 yards away with the right conditions. I'm not so sure if they will always be heard above the sound of the quadcopter.
I've always been able to hear the alarm myself but I usually don't fly very far away (particularly if the quadcopter has been in the air a while).
I'm planning on having a Propeller monitor the battery voltage and use the LEDs to signal when the batteries are getting low. I don't really like the idea of using reduced power (and control) as a low charge indicator.
Hi all,
After testing and way to 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
The footnotes should explain why I made the selections I have.
* For experienced individuals or heavy builds, the consensus in the multirotor community seems to be that you want to disable the cut-off entirely and rely on a timer, low-voltage alarm, or telemetry to alert the pilot that it is time to land. Disabling the Cut Off is achieved by setting Battery type to Ni-xx and Cut Off Voltage to Low. They point out that it generally a lot less expensive to stress the battery than to crash the quad.
However, there are two reasons why I have not chosen this route. First, when LVC kicks in on the new ELEV-8, there is still enough power to maintain a hover and safely land (most of the time). Second, the ELEV-8 is not sold with a Low Voltage Alarm, so early users will need to either rely on a timer (we have an accurate average flight time), or wait until the LVC kicks in. If we totally disable it and they have no timer set up (which will be the case for some), then they will likely both nearly destroy the battery and may crash the quad.
We will strongly recommend that all users purchase a Low Voltage Buzzer (I am currently selecting one to keep in stock at Parallax), especially those who will be flying with a heavy payload (increasing the likelihood of loss of control when LVC occurs). As you point out, you have to be close enough to hear an LVC buzzer (for mine, about 200 feet in quiet areas), or, as I do, keep an eye on the timer and bring it back close when it get towards the end of the expected flight time.
With the Parallax LiPo batteries (3300 mAh), I've found that with an alarm set to 3.5V, I use an average of 2655 mAh (80.46%) w/ a standard deviation of 102.0 mAh. That's right at the upper bound of recommended battery capacity usage (best to leave about 20% capacity). The Middle Cut Off setting will engage at 3.15V, which allows some voltage drop after the alarm sounds, but prevents extreme battery stress. However, I could be convinced that the Low Cut (2.85V) is a better option.
Advanced users (as I have done) will always be able to disable the Cut-Off either by using the program, a programming card, or stick commands.
On the other hand, we could just go with the "you have to time it and/or have a voltage alarm or you will damage your battery/crash."
** I've found that both Low and Middle work fine on the new ELEV-8, but that middle responds better during fast descents and with heavy payloads.
I think HoverFly doesn't want the ESCs to decide when to reduce power. IMO, you want to make sure and use an alarm with your 'copter and probably a timer.
HoverFly may have a good point about not wanting the power to be reduced as you're bringing your quad back for a landing.
I plan to add a menu of sorts to the program so the user can select which setting they wish to use.
Earlier I said something about watching to see how the programming card queries the ESC. If I had read what Roy wrote more carefully, I would have seen the programming card doesn't query the ESC at all. The only time the ESC sends data to the card (that I'm aware of) is when the ESC is first powered on.
Roy's code has provisions to read this data. I'll include some sort of instruction for the user to cycle the power on the ESC so the Propeller can make sure the settings "took".
I was thinking about it from another perspective, that cutting power meant saving what little battery energy was left. My receiver monitors the LiPo voltage and sends it back to the radio, which has an alarm. I also run with a countdown timer that is triggered by the throttle (so you don't forget to turn it on). That countdown timer gives out a single beep on the minutes, which is very handy, you don't have to look at it as often.
With a low battery alarm at 9.7V and the ESC voltage cut at 9.3V (high) I have just a few seconds of alarm prior to the throttle going mushy. Which I'm assuming is the ESC throttle cut kicking in. Generally I can hover or may descend slowly at this point. Fortunately, I haven't been in a situation where I couldn't land safely from loss of battery power.
Since I've never tried flying without the ESC cut enabled, I'm not sure how the quad would behave. I'm guessing that at some point you would experience a natural "throttle cut' from lack of battery energy. More throttle would not equal more lift because of battery depletion. It would seem that the ESC throttle cut just moves the point of power reduction ahead in time when the batteries are above the minimum discharge voltage and there is still a little more capacity left. It appears to be a good scheme to protect the battery with little penalty to flight time.
On the other hand, considering whether to save a $30 battery or a $1500 quad, well I can see why you might want every last drop of battery in some situations. I think I may try other settings and see how it works out.
With the Parallax LiPo batteries (3300 mAh), I've found that with an alarm set to 3.5V, I use an average of 2655 mAh (80.46%) w/ a standard deviation of 102.0 mAh. That's right at the upper bound of recommended battery capacity usage (best to leave about 20% capacity). The Middle Cut Off setting will engage at 3.15V, which allows some voltage drop after the alarm sounds, but prevents extreme battery stress. However, I could be convinced that the Low Cut (2.85V) is a better option.
I'm using about 2600+ mAh on my Parallax LiPo, which seems to be right in line with your data. What is the associated typical flight time? I usually get around 7-1/2 minutes. ("standard" Elev-8 w/ no extra payload).
Side Note: Recently I found that I had been forgetting to set the charger to Balanced versus normal Charge. This of course resulted in less mAh pumped back into the batttery and shorter flight times - doh!.
Advanced users (as I have done) will always be able to disable the Cut-Off either by using the program, a programming card, or stick commands.
On the other hand, we could just go with the "you have to time it and/or have a voltage alarm or you will damage your battery/crash."
My plan is to make a program which allows the user to change any of the parameters. There will be a set of defaults (whatever is recommended by Parallax) but the user will be able to modify the settings if they chose.
I'm interested in what sort of alarm Parallax decides to sell. The alarm I like the most so far is the one pictured above with the built in voltage meter.
While I could monitor the communication between the programming card and the ESC just fine, I couldn't tell which device as sending the data.
I know I could separate the two different signals by using a resistor and an oscilloscope but I'm never been very successful at capturing non-repeating signals with my cheap scope.
I decided to use the Propeller as a signal separator. I plugged the programming card into one I/O pin and the ESC into another. The Propeller passes on whatever is sees on the one pin to the other pin while also mirroring to another I/O pin the incoming message.
Here's the program I used.
CON _clkmode = xtal1 + pll16x
_xinfreq = 5_000_000 '80 MHz
CON
CARD_MASK = 1 << 28
ESC_MASK = 1 << 29
COMBINED_MASK = CARD_MASK | ESC_MASK
CARD_MIRROR_MASK = 1 << 16
ESC_MIRROR_MASK = 1 << 17
HEARTBEAT_LED = 18
PUB main
dira[HEARTBEAT_LED] := 1
cognew(@enter, 0)
repeat
!outa[HEARTBEAT_LED]
waitcnt(clkfreq / 4 + cnt)
DAT org 0
enter or outa, cardMirrorMask
or outa, escMirrorMask
or dira, cardMirrorMask
or dira, escMirrorMask
readBothPins andn dira, combinedMask ' inputs pulled high
nop
{I used a total of 30 nops just to make sure the pins had time to be pulled high.
I imagine this amount could be reduced but I don't know by how much.
The program ends up oscillating if no delay is added.}
waitpne combinedMask, combinedMask ' wait for a pin to go low
mov temp, ina ' find which pin is low
and temp, cardMask wz 'if card low then temp will be zero
if_z jmp #startWatchCardPin
' else assume esc went low
startWatchEscPin or dira, cardMask ' send low pulse from esc to card
andn outa, escMirrorMask ' mirror esc low
waitpeq escMask, escMask ' wait for esc to go high
or outa, escMirrorMask ' mirror esc back high
jmp #readBothPins
'-------------------------------------------------------------------------------
startWatchCardPin or dira, escMask ' send low pulse from card to esc
andn outa, cardMirrorMask
waitpeq cardMask, cardMask ' wait for card to go high
or outa, cardMirrorMask ' mirror card back high
jmp #readBothPins
'-------------------------------------------------------------------------------
cardMask long CARD_MASK
escMask long ESC_MASK
combinedMask long COMBINED_MASK
cardMirrorMask long CARD_MIRROR_MASK
escMirrorMask long ESC_MIRROR_MASK
temp res 1
fit
I've also attached the code to this post. The program requires pull-up resistors (I think). I used the I2C lines since they were already pulled high.
When the ESC is first turned on, it sends some data to the programming card. The programming card then replies with six low pulses (this is also seen in Roy's code).
I'm not sure why the programming card sends so much more data than the ESC.
When the programming card sends the data, the ESC replies with the same six pulses the card had replied with.
I doubt I'll need to use the signal separator much. It looks pretty clear which device sends data when.
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 high ESC voltage cut setting is actually at 9.9V (3.3 v/cell).
The pdf in post #29 shows 2.6 /2.85 / 3.1 Volts per cell. That would yield a 9.3V high cut setting. So is there a typo error or are you using different ESC's?
Also, what is your typical flight time on the 3300mAh Parallax LiPo? Has any testing been done with larger capacity batteries? Hobby King has some higher capacity, lower C rated batteries that could provide MORE FLIGHT TIME. (yeah, I suppose I should just keep a second battery handy...)
....has 20% more capacity at about the same weight. The trade-off is the discharge rate. It is 10C (40 amp) continuous with a 20C peak (80 amp). The 3300 is a 20C (66 amp) continuous.
Flight time of the ELEV-8: 8-10 minutes (3300 mAh Parallax LiPo Battery) or 12-14 minutes (5000 mAh Battery). Flying at MTOW (maximum (recommended) take-off weight) take reduces flight time approximately 25%.
Ken, I should already have all I need to work on this. I don't mind working on this project, I just don't want to be duplicating someone else's efforts. I can use a logic analyzer to watch the communication between the programming card and the ESC to see how it queries the ESC for the settings and attempt to replicate this with the Propeller. I'll get working on this right away unless someone else really wants to do it (it won't hurt my feelings for someone else to do this). As I said, I already have all the gear so I won't be bothering Julia.
Duane et al,
Just a heads-up...I was trying to look at the communication using a Tektronix MSO2024B and standard scope probes. The ESC would not respond when the probe was connected. My assumption is that I was loading the signal line too much. When I would remove the probe the ESC would then respond. I have been meaning to connect my MDO3104 with passive probes, but haven't gotten back to it yet. I also do not know if the Saleae Logic Analyzer will work. But anyone trying this should be aware standard probes may present too much of a load. I'd be interested in hearing your experiences if you manage to capture the signal.
EDIT: Just saw your reply that you already got a capture. As for the pull-ups, I assumed that either the ESC or the Card would have those if required.
Edit (7/30/14): Much of this post is out of date. The ESCs I'm using pull the com line high. The concerns expressed about the Open's line buffers are still valid.
How does Parallax envision the ESC programming software being used?
One application, I had hoped possible, would be to use F10 to load the ESC programming object onto the HoverFly Open board and use the Open board to program all four (or more) ESCs at once and in situ. There are a couple of issues I see to this approach.
A big issue with using the Open or any arbitrary Propeller board to program an ESC is the need for a pull-up resistor on the communication line in order for the ESC to communicate back to the Propeller. From what I can tell of the communication protocol, it's a lot like the data line on the Propeller's I2C bus (open drain I think). Either the Propeller or the ESC can pull the line low when either device transmits data. Without a pull-up, the Propeller can't receive data transmitted from the ESC.
The HoverFly Open board not only doesn't have pull-up resistors on the lines to the ESCs there's a logic level shifter on the line which I imagine is one directional. While it would be nice to get confirmation of the setting properly taking effect, it should still be possible to program the ESCs from the Open or other board without pull-up resistors on the data lines. I think it should be possible to get the pulses from the Propeller to very closely match the pulses from the programming card. I think with more precise timing, the success rate with programming from a propeller should be every bit as high as when programmed from a card. The main drawback from using the Propeller (without a pull-up resistor) instead of a card is lack of ability to receive acknowledgements and not being able to confirm the programming.
I think it's relatively likely, a person purchasing an ELEV-8 wouldn't have another Propeller board on hand. In this case the Open board would need to be used to program the ESCs. If the ability to confirm the settings of the ESC is a high priority, Parallax could provide instructions on how to turn one of the unused I/O pins (P17-P25) into a programming port by adding a pull-up resistor and a ground connection.
The yellow circle was on the original (page 22 of Assembly Guide).
The above diagram shows where a single programming port could be added to the Open board. By using a through hole resistor network, it would relatively easy to add four (or more) programming ports. I don't see a way of confirming the settings of the ESC, using the Open board, without adding a special purpose port. I had wondered about using one or more of the receiver ports but these all have 10K ohm series resistors which would make two way communication with the ESC problematic.
If the ESCs were programmed using a different Propeller board, then there are several options for gaining two way communication with the ESC. For example on the QuickStart board, either of the I2C lines could be used to program the ESC. Since these lines already have pull-up resistors, all that would be required to communicate with the ESC is to connect the ESC's ground to the QuickStart's ground (position # 39) and connect the ESC's signal line to either the I2C SDA or SCK (positions 29 and 31). Any available I/O pin (30 and 31 are not available) on pretty much any Propeller board could be used for two way communication with the ESC if a pull-up resistor were added to the communication line.
My current plan is to have the program check to see if the I/O pin used to communicate with the ESC is high or not. If the pin is high, the program will assume two-way communication is possible and the program will instruct the user when to power on the ESC based on this assumption. If the com line isn't high, the program will assume only one directional communication is possible. I plan to add ways to keep the program from freezing if these assumptions are incorrect.
Main Point of this Post:
Two-way communication between Propeller and ESC will only be possible when there is a pull-up resistor on the communication line. Edit (7/30/14) ESCs (at least the one I'm using) pull the line high.
As for the pull-ups, I assumed that either the ESC or the Card would have those if required.
Chris, I hadn't seen your post before making my last one. The pull-up is in the programming card.
I think the programming cards only comes to life once it receives the initial communication from the ESC. I haven't been able to power the programming card on (with LED lit) without first attaching it to the ESC. (At least this is my present understanding).
Yeah, I replied before I went to the next page to see your reply as well. I guess I should have done a bit more research on the protocol to see it was OC. That would certainly explain the probe loading down the line. Had I placed a pull-up it may have worked. I originally used the code Roy posted and he did not mention a pull-up on the line. I'm learning a lot about ESCs and even R/C radios lately. I couldn't bind my transmitter to my receiver for weeks because I didn't have a binding plug. Ken got me a new receiver and now it seems the "binding plug" is just a shunt of the signal line to ground. So yeah, I need to start doing a little more research apparently.
I'm trying to figure out an intuitive user interface for the programming object.
I'm planning on letting the user change the various options as they would be able to do with a programming card. Of course I don't have LEDs to indicate the current selection but I thought I could use characters to indicate the current selection. Besides the currently selected option, I hope to indicate what the default option is so they can go back to the default after the parameter has been changed.
Here's one possible menu.
First text of DisplayParameters method
Brake 0) [default]>>>Off<<, On
Battery Type 1) LiPo, [default]>>>NiMH<<
Cutoff Type 2) Soft-Cut, [default]>>>Cut-Off<<
Cutoff Voltage 3) Low, Middle, [default]>>>High<<
>>>active>>> Start Mode 4) >>Normal<<, Soft, [default]>Very Soft
Timing Mode 5) Low, Middle, [default]>>>High<<
Song Parameter 6) Song Parameter Not Presently Used
Governor Mode 7) [default]>>>Off<<, On
Enter the parameter number you wish to edit.
Use "+" and "-" to select parameter setting.
Press "h" for more information about the active parameter.
Press "s" to sent these parameters to the ESC.
Press "x" to exit without sending parameters.
I indicate the default option with the marker "[default]>". I don't really like the way this looks.
Here's another possibility.
First text of DisplayParameters method
Brake 0) >>Off<<, On default = Off
Battery Type 1) LiPo, >>NiMH<< default = NiMH
Cutoff Type 2) Soft-Cut, >>Cut-Off<< default = Cut-Off
Cutoff Voltage 3) Low, Middle, >>High<< default = High
Start Mode 4) Normal, Soft, >>Very Soft<< default = Very Soft
Timing Mode 5) Low, Middle, >>High<< default = High
Song Parameter 6) Song Parameter Not Presently Used default = On
Governor Mode 7) >>Off<<, On default = Off
Enter the parameter number you wish to edit.Press "h" for more information about the active parameter.
Press "s" to sent these parameters to the ESC.
Press "x" to exit without sending parameters.
I think I like this second version better than the first.
Here's what it would look like with a parameter selected.
First text of DisplayParameters method
Brake 0) >>Off<<, On default = Off
Battery Type 1) LiPo, >>NiMH<< default = NiMH
Cutoff Type 2) >>Soft-Cut<<, Cut-Off default = Cut-Off
>>>active>>> Cutoff Voltage 3) >>Low<<, Middle, High default = High
Start Mode 4) Normal, Soft, >>Very Soft<< default = Very Soft
Timing Mode 5) Low, Middle, >>High<< default = High
Song Parameter 6) Song Parameter Not Presently Used default = On
Governor Mode 7) Off, >>On<< default = Off
Enter the parameter number you wish to edit.
Use "+" and "-" to select parameter setting.
Press "h" for more information about the active parameter.
Press "s" to sent these parameters to the ESC.
Press "x" to exit without sending parameters.
First text of DisplayHelp method
Cutoff Voltage help goes here.
In the above example, I pressed "h" to display the help information for the active parameter. I'll probably remove the "h" option and just automatically display information about the active parameter.
I'm hoping to take some of the guess work out of programming the ESCs for people new to the hobby.
Text like "First text of DisplayParameters method" is place holder text. I still need to add headings and more instructions.
If any of you have suggestions one what sort of interface to use, I hope you share them.
The defaults are the same options Roy used with his testing (I think) I don't intend to leave the defaults as they are now. The defaults can be changed in the constants.
I've was able to capture nice clean LA traces of each of the options for each parameter both as sent by the programming card and as sent by the ESC. I haven't checked the Propeller's output against these traces yet but I'll do this soon.
I was sure it was the programming card holding the line high (which is does) but the ESC also holds the signal line high. This makes it much easier to have two communication.
I think the HoverFly Open board's line buffer will prevent two way communication, but in general, the program will be able to get confirmation the settings took effect in the ESC.
Good news. I was sure it was the programming card holding the line high (which is does) but the ESC also holds the signal line high. This makes it much easier to have two communication. I think the HoverFly Open board's line buffer will prevent two way communication, but in general, the program will be able to get confirmation the settings took effect in the ESC.
The bad (confusion) news (in my view) is I am wondering why you were able to probe the signal line without issue and I was not. I will test this again with my Passive Probes and see what happens.
The bad (confusion) news (in my view) is I am wondering why you were able to probe the signal line without issue and I was not. I will test this again with my Passive Probes and see what happens.
I also thought I had measured 0V on the ESC signal line when it's not connected to the programming card but my recent measurements don't agree with my memory.
I'm using a "HobbyKing HK-HW30A ESC" it has a large blue "25" and a small white "30". It also says "Turnigy Programming Card Compatible".
I think I purchased this one from HobbyKing but I also have some which came with the ELEV-8. I have a few other ESCs I can experiment with. I'm not sure how much they vary.
Sometime I'll post the traces I got when selecting a "Music" option. I thought the card just told the ESC which song to play but it looks like the card sends all the notes to the song. Some communication pulses took over three seconds to transmit.
If any of you have suggestions one what sort of interface to use, I hope you share them.
.
Current Parameter Setting Default Options
0) Brake = On Off Off, On
1) Battery Type = LiPo NiMH LiPo, NiMH
2) Cutoff Type = Soft-Cut Cut-off Soft-Cut, Cut-Off
3) Cutoff Voltage = High High Low, Middle, High
4) Start Mode = Soft Very Soft Normal, Soft, Very Soft
5) Timing Mode = High High Low, Middle, High
6) Song Parameter = Not Used Not Used Not Used
7) Governor Mode = Off Off Off, On
Press Parameter Number to Change a Setting
Press 'p' to program ESC
Press 'x' to exit
1
Current Parameter Setting Default Options
1) Battery Type = LiPo NiMH LiPo, NiMH
Press '<' or '>' to change the setting
Press 'x' to exit
This parameter is used to select the Battery chemistry in use.
It is used to in combination with CutOff Type and Cutoff Voltage
to determine if Cutoff is used at what voltage it is enabled.
<
Current Parameter Setting Default Options
1) Battery Type =NiMH NiMH LiPo, NiMH
Press '<' or '>' to change the setting
Press 'x' to exit
x
Current Parameter Setting Default Options
0) Brake = On Off Off, On
1) Battery Type = NiMH NiMH LiPo, NiMH
2) Cutoff Type = Soft-Cut Cut-off Soft-Cut, Cut-Off
3) Cutoff Voltage = High High Low, Middle, High
4) Start Mode = Soft Very Soft Normal, Soft, Very Soft
5) Timing Mode = High High Low, Middle, High
6) Song Parameter = Not Used Not Used Not Used
7) Governor Mode = Off Off Off, On
Press Parameter Number to Change a Setting
Press 'p' to program ESC
Press 'x' to exit
Here's a variation of your scheme. I think having the current settings listed together is a little clearer than otherwise.
I'm assuming this is serial input and output from a terminal monitor. I tried to show what the dialogue might look like for a change to the battery type. If you pick the number, that parameter alone is listed with the options and defaults and a description. It is clearly the 'active' parameter under edit. I picked the left/right arrows as buttons for changing the parameter just because they are next to one another and maybe easier to find. When done changing the active parameter you would x back to the 'main' menu and get the full list again.
If you pick the number, that parameter alone is listed with the options and defaults and a description. It is clearly the 'active' parameter under edit. I picked the left/right arrows as buttons for changing the parameter just because they are next to one another and maybe easier to find.
Very nice.
I agree, I think the way you show the display looks much cleaner than my attempts.
I think I'll use your display unless someone comes up with a better way to display the options and settings.
I also hope to show what the settings were when read from the ESC. I'm not sure if there's enough room for another column in the terminal window. The Parallax Serial Terminal will wrap text even if there's room in the window. I'm not sure where this wrapping will occur; I think maximum characters on a row is somewhere around 100.
I'll see if I can fit a "confirmed" column without causing the line to wrap. If not, I'll try to come up with something and post my attempt here in hopes of getting more feedback on how to display the information. I'm also hoping for a better label than "confirmed".
When done changing the active parameter you would x back to the 'main' menu and get the full list again.
I think there's room in the terminal window to display both the full list of parameters and to display the "active" parameter under the full display. As the parameter option is changed, the change will also be reflected in the full display.
I used "+" and "-" as the characters to scroll through the options since I use these characters in my own programs. The more I think about the "<" and ">" characters for changing the options, the more I like them. I'll make the characters used to scroll through the options constants so if the user wants to use something different then the default characters, it won't be hard to change. At this point, I'm inclined to use the arrow keys inequality keys? as the defaults.
I had wondered about using another pair of keys to scroll through the parameters rather than having to enter a number. Since there are fewer than 10 parameters, the single digit number system seems like an okay way to select the parameters.
I guess I could use the "<" and ">" to change the option selected and the "+" and "-" keys to cycle through the parameters. It wouldn't be hard to have both the number way of selecting the parameter and also have a pair of keys to allow the scrolling through the parameters.
One setting I wanted to capture was with each parameter set to its maximum value. So with the farthest right LED lit for each parameter on the card and with all four "Music" LEDs lit, I programmed the ESC while monitoring the signal line with my LA. This is what I got.
If the card isn't sending music, the programming packet lasts for less than half a second. The above "packet" lasts three and a half seconds. I'm pretty sure it should be possible (though I'm not sure if it's ethical) to program the ESC to play any "music" you want.
The ESC does not confirm the notes received on start up. You'll just have to listen to the motors as they play back the music to make sure the data was received correctly.
In case any of you are as ignorant as I was about a year ago, the ESCs don't have speakers or beepers. The motors are the speakers. I think I learned this from Rich on the forum. If you don't have motors plugged into the ESCs you won't hear the various diagnostic beeps. Nor will you be able to hear whatever song you selected to have transmitted to the ESC. BTW, having the motors on your quadcopter play a little tune on start up may sound like a good idea in theory, I assure you it's NOT. Listening to brushless motors play music gets really old real fast (about half way through the first time playing back the song). I don't have any plans of adding the ability to upload songs with this program.
Back to the ESC. While the notes are not sent from the ESC to the card, the following packet is.
Above was what the ESC sent when powered on after being programmed with the pulses seen in the top capture. The pulses circled in red are the acknowledgement sent back from the programming card to the ESC.
I think both the card and the ESC transmissions start with a set of low and high pulses which act as a start bit would in normal asynchronous serial communication. The program written by Frank Zhao waits for a few state changes on the pin and assumes these state changes are the initial data pulses. I think this approach has a severe problem because the first few state changes are likely caused by noise as the ESC is connected.
Below is part of the same trace as shown in the second capture above. The section below is from earlier in the trace as the ESC was being connected.
As you can see, there are several pulses as I connected the ESC to the power source. At the time I connected the power, I wasn't giving any thought to how noisy the connection would look and didn't attempt to make the connection "clean" nor did I purposely make it noisy.
I think this last capture shows the program will need to monitor the pulses and watch for a set with the correct characteristics before assuming the incoming pulses represent real data from the ESC. I'm still hopeful this can be done in Spin, but it wouldn't be a big deal to start up a PASM cog to monitor the pulses. Code written in PASM would be fast enough to capture the pulses and make the comparisons without the overhead of the code causing timing issues. As I have the code now, the code capturing the data is launched in a separate cog so the main cog can act as a watchdog to make sure it doesn't freeze up (both Roy's/Frank's code and my code have the potential of causing the program to freeze).
As I type this, I think I ought to just switch to PASM instead of attempting to get the Spin version to work. I think receiving data back from the ESC will be more challenging than transmitting data to the ESC. I think transmitting the code can likely be done in Spin.
Just as I'm starting to work on moving some of the code to PASM, I decided I should take a look at the noise intervals compared with the overall timing. The noise was within a period of about 1ms as the ESC was turned on. Once the ESC is on, it takes two full seconds before the ESC sends any data. I'm back to thinking this could still work using Spin (at least that's my opinion this hour).
Yesterday I hooked up a spare ESC (as supplied with a 8/2013 Elev-8), motor and Turnigy programming card. I ran a couple of LA traces and saw the noisy stuff you are referring to as I was trying to figure out why my traces didn't look like your initial ones. Today when I went back to look for it I couldn't find that trace (must not have saved it), but did save a few others. Attached is my "startup" trace.
While I was messing around I did play a few of the music entries. It took about 13 seconds to load those. My wife saw me tinkering and heard the "motor" beeping and asked me if I was going to hook it up to the doorbell.
Since there's a two second "quiet time" with the line high before the ESC starts to send data, I'm timing the intervals the line is high and waiting until it has been high at least 1.5 seconds ( STARTUP_ESC_HIGH_TIME). There's also a six second timeout limit (STARTUP_ESC_HIGH_TIMEOUT).
PRI ReadEscDataPulses(index) | timer, startPacketTime, interval, inputState'' replaces TPC_ser_read | index
' reads a byte from a psuedo 10-bit UART
'dira[TCP_PIN_0] := 0 ' input
bufferIndex := 0
readEscDataReturn := 0
interval := 0
timer := cnt
repeat
timer += interval
repeat
inputState := ina[escPin[index]]
interval := cnt - timer
while inputState == 0 and interval < STARTUP_ESC_HIGH_TIMEOUT
if interval => STARTUP_ESC_HIGH_TIMEOUT
readEscDataReturn := string("Timeout while signal line low.")
return
timer += interval
repeat
inputState := ina[escPin[index]]
interval := cnt - timer
while inputState == 1 and interval < STARTUP_ESC_HIGH_TIMEOUT
if interval => STARTUP_ESC_HIGH_TIMEOUT
readEscDataReturn := string("Timeout while signal line high.")
return
while interval =< STARTUP_ESC_HIGH_TIME
readEscDataReturn := string("The signal line was high long enough.")
startPacketTime := timer + interval
Since the code is running in a separate cog, the return value gets lost as the cog stops itself (or is stopped by the main cog). I use the global variable "readEscDataReturn" to learn where the cog had trouble if it quits early.
Frank seem confident his code works but I don't see how his code ignores any noise at start up.
I asked him about this.
I notice the original setting read back from the card is zero. Have you successfully read back your modified settings?
I just don’t like to trust zero data values nor do I trust values with 0xFFFF.
Thank you for taking the time to share your work.
His reply was:
I’ve always had success reading back the values that are set by my code. It’s one of the basic tests to make sure the code actually works.
I wanted to ask if by "reading back the values" he meant with his program or with the programming card but I think my original question annoyed him and I'm too chicken to ask a follow up.
When I tried Roy's original translation, I always received a zero as the data back from the ESC. I don't think the problem was with Roy's translation. I think the original code has trouble with noise on start up. I wonder if Frank used some sort of clean switch to power on the ESC which didn't cause noise.
I still think it was awfully nice of Frank to post his code and what he had done, I'm just not convinced the code can reliably read the data from an ESC.
I wasn't able to capture a trace with the LA attached to the signal line if the programming card wasn't in the circuit until I moved the signal line to I/O pin #28 (I2C clock). Since this has a pull up resistor (on most Propeller boards but not all) it provided the signal the ESC needed to do its thing (send data).
I'm attaching my very early version of the code, in case anyone wants to play along at home. Edit: Sorry, I chickened out. I found too many dumb errors to let the code remain online. I'll post something soon.
This version captures the pulses into an array and then displays them. So far, it doesn't attempt to translate the pulses into useful data.
I know I have a serious bug since the acknowledgement is sent at the wrong time and for some reason the line was held low much too long. But I think this shows Spin is capable of the precision needed to capture these pulses.
Here's the trace from the logic analyzer.
The first part of the trace is from the ESC but the long low period is likely cased by a bug in the program. The mangled acknowledgement starts low instead of high so the ESC doesn't accept it and repeats the transmission (I didn't know it would do this).
In summary, the code is a mess, but IMO, things are looking promising.
The attached zip file is the logic analyzer file.
I was pleasantly surprised how well the LA intervals matched those measured in Spin. The intervals listed above (out from the code) are within a few hundredths of a millisecond of the intervals captured with the LA.
Though now I'm back to thinking we need a pull-up resistor on the line.
Edit: I found too many errors in my code (the text describing what was going on was opposite of reality). I'll clean it up a little (it will still be a mess) and post it soon.
Edit: I decided it was too cowardly to remove the code. It's back with anti-debug statements (which state the opposite of what is really happening). Use at your own risk.
Edit: I found the error causing the delayed acknowledgement. I'll have an update soon (I think).
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.
In summary, the code is a mess, but IMO, things are looking promising.
I admire your optimism. It is nice that you are airing all the dirty laundry that usually gets swept under the rug... and it does seem promising from here. ;-)
May try your code soon - we'll see how things go tonight....
BTW, I was surprised that the ESC I was fooling around with was getting quite warm just from a few minutes of testing. May be those linear regulators knocking down 12V to 5? (I would guess the shrinktube around the board was 130-140F [rule-of thumb 145F is too hot to maintain contact]).
Comments
HoverFly may have a good point about not wanting the power to be reduced as you're bringing your quad back for a landing.
I plan to add a menu of sorts to the program so the user can select which setting they wish to use.
Earlier I said something about watching to see how the programming card queries the ESC. If I had read what Roy wrote more carefully, I would have seen the programming card doesn't query the ESC at all. The only time the ESC sends data to the card (that I'm aware of) is when the ESC is first powered on.
Roy's code has provisions to read this data. I'll include some sort of instruction for the user to cycle the power on the ESC so the Propeller can make sure the settings "took".
I'm going to have to look at this tomorrow. I need to re older all my ESC connectors to fit my wiring harness.
I'm sure these alarms have paid for themselves many times over by warning me of LiPo packs I left connected which would have been ruined if I hadn't had an alarm on them.
I'm pretty sure they could be heard 100 yards away with the right conditions. I'm not so sure if they will always be heard above the sound of the quadcopter.
I've always been able to hear the alarm myself but I usually don't fly very far away (particularly if the quadcopter has been in the air a while).
I'm planning on having a Propeller monitor the battery voltage and use the LEDs to signal when the batteries are getting low. I don't really like the idea of using reduced power (and control) as a low charge indicator.
After testing and way to 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
The footnotes should explain why I made the selections I have.
* For experienced individuals or heavy builds, the consensus in the multirotor community seems to be that you want to disable the cut-off entirely and rely on a timer, low-voltage alarm, or telemetry to alert the pilot that it is time to land. Disabling the Cut Off is achieved by setting Battery type to Ni-xx and Cut Off Voltage to Low. They point out that it generally a lot less expensive to stress the battery than to crash the quad.
However, there are two reasons why I have not chosen this route. First, when LVC kicks in on the new ELEV-8, there is still enough power to maintain a hover and safely land (most of the time). Second, the ELEV-8 is not sold with a Low Voltage Alarm, so early users will need to either rely on a timer (we have an accurate average flight time), or wait until the LVC kicks in. If we totally disable it and they have no timer set up (which will be the case for some), then they will likely both nearly destroy the battery and may crash the quad.
We will strongly recommend that all users purchase a Low Voltage Buzzer (I am currently selecting one to keep in stock at Parallax), especially those who will be flying with a heavy payload (increasing the likelihood of loss of control when LVC occurs). As you point out, you have to be close enough to hear an LVC buzzer (for mine, about 200 feet in quiet areas), or, as I do, keep an eye on the timer and bring it back close when it get towards the end of the expected flight time.
With the Parallax LiPo batteries (3300 mAh), I've found that with an alarm set to 3.5V, I use an average of 2655 mAh (80.46%) w/ a standard deviation of 102.0 mAh. That's right at the upper bound of recommended battery capacity usage (best to leave about 20% capacity). The Middle Cut Off setting will engage at 3.15V, which allows some voltage drop after the alarm sounds, but prevents extreme battery stress. However, I could be convinced that the Low Cut (2.85V) is a better option.
Advanced users (as I have done) will always be able to disable the Cut-Off either by using the program, a programming card, or stick commands.
On the other hand, we could just go with the "you have to time it and/or have a voltage alarm or you will damage your battery/crash."
** I've found that both Low and Middle work fine on the new ELEV-8, but that middle responds better during fast descents and with heavy payloads.
I was thinking about it from another perspective, that cutting power meant saving what little battery energy was left. My receiver monitors the LiPo voltage and sends it back to the radio, which has an alarm. I also run with a countdown timer that is triggered by the throttle (so you don't forget to turn it on). That countdown timer gives out a single beep on the minutes, which is very handy, you don't have to look at it as often.
With a low battery alarm at 9.7V and the ESC voltage cut at 9.3V (high) I have just a few seconds of alarm prior to the throttle going mushy. Which I'm assuming is the ESC throttle cut kicking in. Generally I can hover or may descend slowly at this point. Fortunately, I haven't been in a situation where I couldn't land safely from loss of battery power.
Since I've never tried flying without the ESC cut enabled, I'm not sure how the quad would behave. I'm guessing that at some point you would experience a natural "throttle cut' from lack of battery energy. More throttle would not equal more lift because of battery depletion. It would seem that the ESC throttle cut just moves the point of power reduction ahead in time when the batteries are above the minimum discharge voltage and there is still a little more capacity left. It appears to be a good scheme to protect the battery with little penalty to flight time.
On the other hand, considering whether to save a $30 battery or a $1500 quad, well I can see why you might want every last drop of battery in some situations. I think I may try other settings and see how it works out.
-Russ
I'm using about 2600+ mAh on my Parallax LiPo, which seems to be right in line with your data. What is the associated typical flight time? I usually get around 7-1/2 minutes. ("standard" Elev-8 w/ no extra payload).
Side Note: Recently I found that I had been forgetting to set the charger to Balanced versus normal Charge. This of course resulted in less mAh pumped back into the batttery and shorter flight times - doh!.
-Russ
My plan is to make a program which allows the user to change any of the parameters. There will be a set of defaults (whatever is recommended by Parallax) but the user will be able to modify the settings if they chose.
I'm interested in what sort of alarm Parallax decides to sell. The alarm I like the most so far is the one pictured above with the built in voltage meter.
I know I could separate the two different signals by using a resistor and an oscilloscope but I'm never been very successful at capturing non-repeating signals with my cheap scope.
I decided to use the Propeller as a signal separator. I plugged the programming card into one I/O pin and the ESC into another. The Propeller passes on whatever is sees on the one pin to the other pin while also mirroring to another I/O pin the incoming message.
Here's the program I used.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 '80 MHz CON CARD_MASK = 1 << 28 ESC_MASK = 1 << 29 COMBINED_MASK = CARD_MASK | ESC_MASK CARD_MIRROR_MASK = 1 << 16 ESC_MIRROR_MASK = 1 << 17 HEARTBEAT_LED = 18 PUB main dira[HEARTBEAT_LED] := 1 cognew(@enter, 0) repeat !outa[HEARTBEAT_LED] waitcnt(clkfreq / 4 + cnt) DAT org 0 enter or outa, cardMirrorMask or outa, escMirrorMask or dira, cardMirrorMask or dira, escMirrorMask readBothPins andn dira, combinedMask ' inputs pulled high nop {I used a total of 30 nops just to make sure the pins had time to be pulled high. I imagine this amount could be reduced but I don't know by how much. The program ends up oscillating if no delay is added.} waitpne combinedMask, combinedMask ' wait for a pin to go low mov temp, ina ' find which pin is low and temp, cardMask wz 'if card low then temp will be zero if_z jmp #startWatchCardPin ' else assume esc went low startWatchEscPin or dira, cardMask ' send low pulse from esc to card andn outa, escMirrorMask ' mirror esc low waitpeq escMask, escMask ' wait for esc to go high or outa, escMirrorMask ' mirror esc back high jmp #readBothPins '------------------------------------------------------------------------------- startWatchCardPin or dira, escMask ' send low pulse from card to esc andn outa, cardMirrorMask waitpeq cardMask, cardMask ' wait for card to go high or outa, cardMirrorMask ' mirror card back high jmp #readBothPins '------------------------------------------------------------------------------- cardMask long CARD_MASK escMask long ESC_MASK combinedMask long COMBINED_MASK cardMirrorMask long CARD_MIRROR_MASK escMirrorMask long ESC_MIRROR_MASK temp res 1 fitI've also attached the code to this post. The program requires pull-up resistors (I think). I used the I2C lines since they were already pulled high.
When the ESC is first turned on, it sends some data to the programming card. The programming card then replies with six low pulses (this is also seen in Roy's code).
I'm not sure why the programming card sends so much more data than the ESC.
When the programming card sends the data, the ESC replies with the same six pulses the card had replied with.
I doubt I'll need to use the signal separator much. It looks pretty clear which device sends data when.
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 pdf in post #29 shows 2.6 /2.85 / 3.1 Volts per cell. That would yield a 9.3V high cut setting. So is there a typo error or are you using different ESC's?
Also, what is your typical flight time on the 3300mAh Parallax LiPo? Has any testing been done with larger capacity batteries? Hobby King has some higher capacity, lower C rated batteries that could provide MORE FLIGHT TIME.
This one: http://www.hobbyking.com/hobbyking/store/__56846__multistar_high_capacity_3s_4000mah_multi_rotor_lipo_pack.html
....has 20% more capacity at about the same weight. The trade-off is the discharge rate. It is 10C (40 amp) continuous with a 20C peak (80 amp). The 3300 is a 20C (66 amp) continuous.
-Russ
-Russ
Duane et al,
Just a heads-up...I was trying to look at the communication using a Tektronix MSO2024B and standard scope probes. The ESC would not respond when the probe was connected. My assumption is that I was loading the signal line too much. When I would remove the probe the ESC would then respond. I have been meaning to connect my MDO3104 with passive probes, but haven't gotten back to it yet. I also do not know if the Saleae Logic Analyzer will work. But anyone trying this should be aware standard probes may present too much of a load. I'd be interested in hearing your experiences if you manage to capture the signal.
EDIT: Just saw your reply that you already got a capture. As for the pull-ups, I assumed that either the ESC or the Card would have those if required.
How does Parallax envision the ESC programming software being used?
One application, I had hoped possible, would be to use F10 to load the ESC programming object onto the HoverFly Open board and use the Open board to program all four (or more) ESCs at once and in situ. There are a couple of issues I see to this approach.
A big issue with using the Open or any arbitrary Propeller board to program an ESC is the need for a pull-up resistor on the communication line in order for the ESC to communicate back to the Propeller. From what I can tell of the communication protocol, it's a lot like the data line on the Propeller's I2C bus (open drain I think). Either the Propeller or the ESC can pull the line low when either device transmits data. Without a pull-up, the Propeller can't receive data transmitted from the ESC.
The HoverFly Open board not only doesn't have pull-up resistors on the lines to the ESCs there's a logic level shifter on the line which I imagine is one directional. While it would be nice to get confirmation of the setting properly taking effect, it should still be possible to program the ESCs from the Open or other board without pull-up resistors on the data lines. I think it should be possible to get the pulses from the Propeller to very closely match the pulses from the programming card. I think with more precise timing, the success rate with programming from a propeller should be every bit as high as when programmed from a card. The main drawback from using the Propeller (without a pull-up resistor) instead of a card is lack of ability to receive acknowledgements and not being able to confirm the programming.
I think it's relatively likely, a person purchasing an ELEV-8 wouldn't have another Propeller board on hand. In this case the Open board would need to be used to program the ESCs. If the ability to confirm the settings of the ESC is a high priority, Parallax could provide instructions on how to turn one of the unused I/O pins (P17-P25) into a programming port by adding a pull-up resistor and a ground connection.
The yellow circle was on the original (page 22 of Assembly Guide).
The above diagram shows where a single programming port could be added to the Open board. By using a through hole resistor network, it would relatively easy to add four (or more) programming ports. I don't see a way of confirming the settings of the ESC, using the Open board, without adding a special purpose port. I had wondered about using one or more of the receiver ports but these all have 10K ohm series resistors which would make two way communication with the ESC problematic.
If the ESCs were programmed using a different Propeller board, then there are several options for gaining two way communication with the ESC. For example on the QuickStart board, either of the I2C lines could be used to program the ESC. Since these lines already have pull-up resistors, all that would be required to communicate with the ESC is to connect the ESC's ground to the QuickStart's ground (position # 39) and connect the ESC's signal line to either the I2C SDA or SCK (positions 29 and 31). Any available I/O pin (30 and 31 are not available) on pretty much any Propeller board could be used for two way communication with the ESC if a pull-up resistor were added to the communication line.
My current plan is to have the program check to see if the I/O pin used to communicate with the ESC is high or not. If the pin is high, the program will assume two-way communication is possible and the program will instruct the user when to power on the ESC based on this assumption. If the com line isn't high, the program will assume only one directional communication is possible. I plan to add ways to keep the program from freezing if these assumptions are incorrect.
Main Point of this Post:
Two-way communication between Propeller and ESC will only be possible when there is a pull-up resistor on the communication line. Edit (7/30/14) ESCs (at least the one I'm using) pull the line high.
Chris, I hadn't seen your post before making my last one. The pull-up is in the programming card.
I think the programming cards only comes to life once it receives the initial communication from the ESC. I haven't been able to power the programming card on (with LED lit) without first attaching it to the ESC. (At least this is my present understanding).
I'm planning on letting the user change the various options as they would be able to do with a programming card. Of course I don't have LEDs to indicate the current selection but I thought I could use characters to indicate the current selection. Besides the currently selected option, I hope to indicate what the default option is so they can go back to the default after the parameter has been changed.
Here's one possible menu.
First text of DisplayParameters method Brake 0) [default]>>>Off<<, On Battery Type 1) LiPo, [default]>>>NiMH<< Cutoff Type 2) Soft-Cut, [default]>>>Cut-Off<< Cutoff Voltage 3) Low, Middle, [default]>>>High<< >>>active>>> Start Mode 4) >>Normal<<, Soft, [default]>Very Soft Timing Mode 5) Low, Middle, [default]>>>High<< Song Parameter 6) Song Parameter Not Presently Used Governor Mode 7) [default]>>>Off<<, On Enter the parameter number you wish to edit. Use "+" and "-" to select parameter setting. Press "h" for more information about the active parameter. Press "s" to sent these parameters to the ESC. Press "x" to exit without sending parameters.I indicate the default option with the marker "[default]>". I don't really like the way this looks.
Here's another possibility.
First text of DisplayParameters method Brake 0) >>Off<<, On default = Off Battery Type 1) LiPo, >>NiMH<< default = NiMH Cutoff Type 2) Soft-Cut, >>Cut-Off<< default = Cut-Off Cutoff Voltage 3) Low, Middle, >>High<< default = High Start Mode 4) Normal, Soft, >>Very Soft<< default = Very Soft Timing Mode 5) Low, Middle, >>High<< default = High Song Parameter 6) Song Parameter Not Presently Used default = On Governor Mode 7) >>Off<<, On default = Off Enter the parameter number you wish to edit.Press "h" for more information about the active parameter. Press "s" to sent these parameters to the ESC. Press "x" to exit without sending parameters.I think I like this second version better than the first.
Here's what it would look like with a parameter selected.
First text of DisplayParameters method Brake 0) >>Off<<, On default = Off Battery Type 1) LiPo, >>NiMH<< default = NiMH Cutoff Type 2) >>Soft-Cut<<, Cut-Off default = Cut-Off >>>active>>> Cutoff Voltage 3) >>Low<<, Middle, High default = High Start Mode 4) Normal, Soft, >>Very Soft<< default = Very Soft Timing Mode 5) Low, Middle, >>High<< default = High Song Parameter 6) Song Parameter Not Presently Used default = On Governor Mode 7) Off, >>On<< default = Off Enter the parameter number you wish to edit. Use "+" and "-" to select parameter setting. Press "h" for more information about the active parameter. Press "s" to sent these parameters to the ESC. Press "x" to exit without sending parameters. First text of DisplayHelp method Cutoff Voltage help goes here.In the above example, I pressed "h" to display the help information for the active parameter. I'll probably remove the "h" option and just automatically display information about the active parameter.
I'm hoping to take some of the guess work out of programming the ESCs for people new to the hobby.
Text like "First text of DisplayParameters method" is place holder text. I still need to add headings and more instructions.
If any of you have suggestions one what sort of interface to use, I hope you share them.
The defaults are the same options Roy used with his testing (I think) I don't intend to leave the defaults as they are now. The defaults can be changed in the constants.
I've was able to capture nice clean LA traces of each of the options for each parameter both as sent by the programming card and as sent by the ESC. I haven't checked the Propeller's output against these traces yet but I'll do this soon.
I was sure it was the programming card holding the line high (which is does) but the ESC also holds the signal line high. This makes it much easier to have two communication.
I think the HoverFly Open board's line buffer will prevent two way communication, but in general, the program will be able to get confirmation the settings took effect in the ESC.
The bad (confusion) news (in my view) is I am wondering why you were able to probe the signal line without issue and I was not. I will test this again with my Passive Probes and see what happens.
I also thought I had measured 0V on the ESC signal line when it's not connected to the programming card but my recent measurements don't agree with my memory.
I'm using a "HobbyKing HK-HW30A ESC" it has a large blue "25" and a small white "30". It also says "Turnigy Programming Card Compatible".
I think I purchased this one from HobbyKing but I also have some which came with the ELEV-8. I have a few other ESCs I can experiment with. I'm not sure how much they vary.
Sometime I'll post the traces I got when selecting a "Music" option. I thought the card just told the ESC which song to play but it looks like the card sends all the notes to the song. Some communication pulses took over three seconds to transmit.
Here's a variation of your scheme. I think having the current settings listed together is a little clearer than otherwise.
I'm assuming this is serial input and output from a terminal monitor. I tried to show what the dialogue might look like for a change to the battery type. If you pick the number, that parameter alone is listed with the options and defaults and a description. It is clearly the 'active' parameter under edit. I picked the left/right arrows as buttons for changing the parameter just because they are next to one another and maybe easier to find. When done changing the active parameter you would x back to the 'main' menu and get the full list again.
-Russ
Very nice.
I agree, I think the way you show the display looks much cleaner than my attempts.
I think I'll use your display unless someone comes up with a better way to display the options and settings.
I also hope to show what the settings were when read from the ESC. I'm not sure if there's enough room for another column in the terminal window. The Parallax Serial Terminal will wrap text even if there's room in the window. I'm not sure where this wrapping will occur; I think maximum characters on a row is somewhere around 100.
I'll see if I can fit a "confirmed" column without causing the line to wrap. If not, I'll try to come up with something and post my attempt here in hopes of getting more feedback on how to display the information. I'm also hoping for a better label than "confirmed".
I think there's room in the terminal window to display both the full list of parameters and to display the "active" parameter under the full display. As the parameter option is changed, the change will also be reflected in the full display.
I used "+" and "-" as the characters to scroll through the options since I use these characters in my own programs. The more I think about the "<" and ">" characters for changing the options, the more I like them. I'll make the characters used to scroll through the options constants so if the user wants to use something different then the default characters, it won't be hard to change. At this point, I'm inclined to use the arrow keys inequality keys? as the defaults.
I had wondered about using another pair of keys to scroll through the parameters rather than having to enter a number. Since there are fewer than 10 parameters, the single digit number system seems like an okay way to select the parameters.
I guess I could use the "<" and ">" to change the option selected and the "+" and "-" keys to cycle through the parameters. It wouldn't be hard to have both the number way of selecting the parameter and also have a pair of keys to allow the scrolling through the parameters.
If the card isn't sending music, the programming packet lasts for less than half a second. The above "packet" lasts three and a half seconds. I'm pretty sure it should be possible (though I'm not sure if it's ethical) to program the ESC to play any "music" you want.
The ESC does not confirm the notes received on start up. You'll just have to listen to the motors as they play back the music to make sure the data was received correctly.
In case any of you are as ignorant as I was about a year ago, the ESCs don't have speakers or beepers. The motors are the speakers. I think I learned this from Rich on the forum. If you don't have motors plugged into the ESCs you won't hear the various diagnostic beeps. Nor will you be able to hear whatever song you selected to have transmitted to the ESC. BTW, having the motors on your quadcopter play a little tune on start up may sound like a good idea in theory, I assure you it's NOT. Listening to brushless motors play music gets really old real fast (about half way through the first time playing back the song). I don't have any plans of adding the ability to upload songs with this program.
Back to the ESC. While the notes are not sent from the ESC to the card, the following packet is.
Above was what the ESC sent when powered on after being programmed with the pulses seen in the top capture. The pulses circled in red are the acknowledgement sent back from the programming card to the ESC.
I think both the card and the ESC transmissions start with a set of low and high pulses which act as a start bit would in normal asynchronous serial communication. The program written by Frank Zhao waits for a few state changes on the pin and assumes these state changes are the initial data pulses. I think this approach has a severe problem because the first few state changes are likely caused by noise as the ESC is connected.
Below is part of the same trace as shown in the second capture above. The section below is from earlier in the trace as the ESC was being connected.
As you can see, there are several pulses as I connected the ESC to the power source. At the time I connected the power, I wasn't giving any thought to how noisy the connection would look and didn't attempt to make the connection "clean" nor did I purposely make it noisy.
I think this last capture shows the program will need to monitor the pulses and watch for a set with the correct characteristics before assuming the incoming pulses represent real data from the ESC. I'm still hopeful this can be done in Spin, but it wouldn't be a big deal to start up a PASM cog to monitor the pulses. Code written in PASM would be fast enough to capture the pulses and make the comparisons without the overhead of the code causing timing issues. As I have the code now, the code capturing the data is launched in a separate cog so the main cog can act as a watchdog to make sure it doesn't freeze up (both Roy's/Frank's code and my code have the potential of causing the program to freeze).
As I type this, I think I ought to just switch to PASM instead of attempting to get the Spin version to work. I think receiving data back from the ESC will be more challenging than transmitting data to the ESC. I think transmitting the code can likely be done in Spin.
While I was messing around I did play a few of the music entries. It took about 13 seconds to load those. My wife saw me tinkering and heard the "motor" beeping and asked me if I was going to hook it up to the doorbell.
-Russ
PRI ReadEscDataPulses(index) | timer, startPacketTime, interval, inputState'' replaces TPC_ser_read | index ' reads a byte from a psuedo 10-bit UART 'dira[TCP_PIN_0] := 0 ' input bufferIndex := 0 readEscDataReturn := 0 interval := 0 timer := cnt repeat timer += interval repeat inputState := ina[escPin[index]] interval := cnt - timer while inputState == 0 and interval < STARTUP_ESC_HIGH_TIMEOUT if interval => STARTUP_ESC_HIGH_TIMEOUT readEscDataReturn := string("Timeout while signal line low.") return timer += interval repeat inputState := ina[escPin[index]] interval := cnt - timer while inputState == 1 and interval < STARTUP_ESC_HIGH_TIMEOUT if interval => STARTUP_ESC_HIGH_TIMEOUT readEscDataReturn := string("Timeout while signal line high.") return while interval =< STARTUP_ESC_HIGH_TIME readEscDataReturn := string("The signal line was high long enough.") startPacketTime := timer + intervalSince the code is running in a separate cog, the return value gets lost as the cog stops itself (or is stopped by the main cog). I use the global variable "readEscDataReturn" to learn where the cog had trouble if it quits early.
Frank seem confident his code works but I don't see how his code ignores any noise at start up.
I asked him about this.
His reply was:
I wanted to ask if by "reading back the values" he meant with his program or with the programming card but I think my original question annoyed him and I'm too chicken to ask a follow up.
When I tried Roy's original translation, I always received a zero as the data back from the ESC. I don't think the problem was with Roy's translation. I think the original code has trouble with noise on start up. I wonder if Frank used some sort of clean switch to power on the ESC which didn't cause noise.
I still think it was awfully nice of Frank to post his code and what he had done, I'm just not convinced the code can reliably read the data from an ESC.
I wasn't able to capture a trace with the LA attached to the signal line if the programming card wasn't in the circuit until I moved the signal line to I/O pin #28 (I2C clock). Since this has a pull up resistor (on most Propeller boards but not all) it provided the signal the ESC needed to do its thing (send data).
I'm attaching my very early version of the code, in case anyone wants to play along at home. Edit: Sorry, I chickened out. I found too many dumb errors to let the code remain online. I'll post something soon.
This version captures the pulses into an array and then displays them. So far, it doesn't attempt to translate the pulses into useful data.
Here's what the Propeller captured.
readEscDataReturn = Successfully received packet and sent acknowledgement. bufferIndex = 14 Pulses (in milliseconds) [0] 2.559, 2.537, 2.540, 7.632, 2.540, 2.537, 2.540, 7.632, 2.540, 2.537 [10] 5.087, 12.728, 5.087, 6.976, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000 [20] 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000 [30] 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000 [40] 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000 [50] 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000 [60] 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000 [70] 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000 [80] 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000 [90] 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000 End of ProgramI know I have a serious bug since the acknowledgement is sent at the wrong time and for some reason the line was held low much too long. But I think this shows Spin is capable of the precision needed to capture these pulses.
Here's the trace from the logic analyzer.
The first part of the trace is from the ESC but the long low period is likely cased by a bug in the program. The mangled acknowledgement starts low instead of high so the ESC doesn't accept it and repeats the transmission (I didn't know it would do this).
In summary, the code is a mess, but IMO, things are looking promising.
The attached zip file is the logic analyzer file.
I was pleasantly surprised how well the LA intervals matched those measured in Spin. The intervals listed above (out from the code) are within a few hundredths of a millisecond of the intervals captured with the LA.
Though now I'm back to thinking we need a pull-up resistor on the line.
Edit: I found too many errors in my code (the text describing what was going on was opposite of reality). I'll clean it up a little (it will still be a mess) and post it soon.
Edit: I decided it was too cowardly to remove the code. It's back with anti-debug statements (which state the opposite of what is really happening). Use at your own risk.
Edit: I found the error causing the delayed acknowledgement. I'll have an update soon (I think).
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.
I admire your optimism.
May try your code soon - we'll see how things go tonight....
BTW, I was surprised that the ESC I was fooling around with was getting quite warm just from a few minutes of testing. May be those linear regulators knocking down 12V to 5? (I would guess the shrinktube around the board was 130-140F [rule-of thumb 145F is too hot to maintain contact]).
-Russ