Also does the new version solve the data log full problem? Flybarless controllers won’t let you power up at full throttle to clear the data log? That’s also a problem with multirotors.

I'm wondering how CC can solve this problem, because it is complicated.

1) You don't always want to clear the memory, especially if you are logging several flights.

2) If the memory fills up, does the user really want to clear the entire log?

3) It is probably difficult for the microcontroller to figure out how to clear a single session, since due to data compression, it has a variable length. Then to take care of that, you would have to program in a more (I think) sophisticated file handling system. And does it do this on the "fly". I am not sure I want the micro to be taking care of bookkeeping while it is also keeping track of commutations!

4) Also due to the compression, it really isn't possible to simply overwrite previous data, since you may not really know how large (in bytes) each time stamp data point(s) is/are. So you are in danger of leaving partially cleared sessions in memory. Some of this stuff can be figured out offline where you can program a sophisticated reading program, but how to do it in realtime, with the micro handling a real motor (with lots of power going through it) isn't obvious to me.

I am not saying it can't be done, but just that there are some complications.

As to the full stick to enter programming/data clearing, this is probably a tough nut to crack too, because there are now so many "smart" things between the ESC and the battery that have their own safety systems. Back in the old days of simple receivers, you could use low, high, and everything in-between as special cases, but as you point out, the ESC has something between it and the receiver throttle channel output, it probably becomes almost impossible to have a simple coding that the ESC can use to enter specific states (like arming, programming).

I suppose you could have a "Morse Code" type affair, but most of us would screw it up (I know I would). The only thing I can think of is to use the Field Card plugged into the Castle Quick connect. I don't know if the Field card already supports stuff like this or not--I have one, but haven't actually used it for anything.

Long post--it would be good to hear something back from CC on where they are going here in the world where their simple stick programming is becoming hard to almost impossible to use.

I'm wondering how CC can solve this problem, because it is complicated.

1) You don't always want to clear the memory, especially if you are logging several flights.

2) If the memory fills up, does the user really want to clear the entire log?

3) It is probably difficult for the microcontroller to figure out how to clear a single session, since due to data compression, it has a variable length. Then to take care of that, you would have to program in a more (I think) sophisticated file handling system. And does it do this on the "fly". I am not sure I want the micro to be taking care of bookkeeping while it is also keeping track of commutations!

4) Also due to the compression, it really isn't possible to simply overwrite previous data, since you may not really know how large (in bytes) each time stamp data point(s) is/are. So you are in danger of leaving partially cleared sessions in memory. Some of this stuff can be figured out offline where you can program a sophisticated reading program, but how to do it in realtime, with the micro handling a real motor (with lots of power going through it) isn't obvious to me.

I am not saying it can't be done, but just that there are some complications.

As to the full stick to enter programming/data clearing, this is probably a tough nut to crack too, because there are now so many "smart" things between the ESC and the battery that have their own safety systems. Back in the old days of simple receivers, you could use low, high, and everything in-between as special cases, but as you point out, the ESC has something between it and the receiver throttle channel output, it probably becomes almost impossible to have a simple coding that the ESC can use to enter specific states (like arming, programming).

I suppose you could have a "Morse Code" type affair, but most of us would screw it up (I know I would). The only thing I can think of is to use the Field Card plugged into the Castle Quick connect. I don't know if the Field card already supports stuff like this or not--I have one, but haven't actually used it for anything.

Long post--it would be good to hear something back from CC on where they are going here in the world where their simple stick programming is becoming hard to almost impossible to use.

Well itís fairly useless they way it is now so they need to do something.

The most important thing is if you have a problem you always want to have the latest data available so that you can see what happened.

Maybe there should be some selectable options:
1. Do they way it is now
2. Auto clear the entire log when it gets full
3. Clear on power up if the Castle Link is not connected.
4. How about some other suggestions to help Castle out. They have been struggling with this problem for a couple of years and itís obvious that they need some new ideas.

Thats a step in the right direction. But I had envisioned a feature integrated onto the Tx and telemetry Tx on the model. Log review on Tx screen as well as download to PC, which should be using Bluetooth.

I'm wondering how CC can solve this problem, because it is complicated.

In terms of what it should do, I don't see anything particularly complicated here. They should just record the last thirty minutes (or whatever the buffer holds). I suspect at this point it would be a substantial change for Castle, though, probably in h/w as well as s/w.

As a quick fix, perhaps Castle could add a log reset function to the field card?