Originally Posted by grumpy42

If I am reading this correctly, it seems that your are writing the telemetry data in "real time". It seems that it it would make more sense buffer the data and perform periodic writes.

Yes and no. Without getting into the various technical aspects, early on I made a quick streaming tool for testing telemetry that pointed out a need for significantly more work if it were to be productized for the DX7s/DX8 platform. The DX10t has a faster processor that does not have the same limitations, so enabling it in the baseline product was a non-issue.

As for buffering, that's actually how the file system works.

That is unfortunate. I would also be content with a module that plugs into the telemetry module and records to either internal memory a MicroSD card. Perhaps a external receiver that records telemetry data (not the STi since not everyone owns a compatible product).

You won't be content, then you couldn't be "grumpy" any more! You'd have to change your screen name

There are people who have figured out how to add their own module into their DX8 to record the telemetry data to a card in the similar manner as others did for Hitec.

So, if the DX10t gets logging then there is no "technical" reason that the DX8 can't support logging.

There is, as noted above.

Andy

Andy, OK logging is not a viable option for the DX8. But there are other features that people are willing to pay extra for. What did you think about my idea?

Originally Posted by jhroof

Andy, OK logging is not a viable option for the DX8. But there are other features that people are willing to pay extra for. What did you think about my idea?

+1 here

Originally Posted by AndyKunz

Yes and no. Without getting into the various technical aspects, early on I made a quick streaming tool for testing telemetry that pointed out a need for significantly more work if it were to be productized for the DX7s/DX8 platform. The DX10t has a faster processor that does not have the same limitations, so enabling it in the baseline product was a non-issue.

As for buffering, that's actually how the file system works.



You won't be content, then you couldn't be "grumpy" any more! You'd have to change your screen name

There are people who have figured out how to add their own module into their DX8 to record the telemetry data to a card in the similar manner as others did for Hitec.



There is, as noted above.

Andy

What if the data was written to a DB instead of a text file ? Access or SQL Theres gotta be a way to get around the write, dump, re write, allocate, truncate etc.

Originally Posted by jhroof

Andy, OK logging is not a viable option for the DX8. But there are other features that people are willing to pay extra for. What did you think about my idea?

Sorry, I saw it and forgot to reply earlier. It's a technically-possible idea, and I designed that into the radio from day 1. A decision to think about going that route is way above my pay grade.

Originally Posted by FlyHighSelllow

What if the data was written to a DB instead of a text file ? Access or SQL Theres gotta be a way to get around the write, dump, re write, allocate, truncate etc.

Databases are far more expensive in time and memory!!! You have to add the duration of the normal write stuff (that already takes too long) to the database system's overhead.

It's not even being written to a text file, it's the pure binary data off the air. There's no write, dump, ... sequence - it's a matter of write, write, write... to buffer until sector full then flush to disk, write...to buffer until sector full then flush to disk, ... until allocation unit full then read directory sectors, allocate more AU's to the file and flush the updated directory sectors to disk, then start to write, write, write... data again.

The thing that takes most time, especially with a card that has files on it already, is what happens when an allocation unit needs to be added to the file. Sometimes the file system needs to read (and write) multiple directory sectors, and those take time.

Believe me, there's nobody who wants data logging in the DX8 more than me. If I could have slipped it in unnoticed, I probably would have!

Andy

Originally Posted by FlyHighSelllow

What if the data was written to a DB instead of a text file ? Access or SQL Theres gotta be a way to get around the write, dump, re write, allocate, truncate etc.

I believe that writing sequentially to a file is really the simplest/fastest way to go.

Originally Posted by AndyKunz

The DX10t has a faster processor that does not have the same limitations, so enabling it in the baseline product was a non-issue.

I was afraid that it was a processor limitation. Is it feasible to have logging on the DX8 but only have it work with a 22ms frame rate?

I am assuming that everything is executed within a control loop, so all stick/switch reading, applying mixes, updating UI, etc. must be completed within the "frame rate window". So, if the frame rate is limited then there may be sufficient time to complete the necessary file system operations.

Just a thought (and perhaps not a good one).

Originally Posted by AndyKunz

You won't be content, then you couldn't be "grumpy" any more! You'd have to change your screen name

NEVER! There is always something to complain about!

Originally Posted by grumpy42

I was afraid that it was a processor limitation. Is it feasible to have logging on the DX8 but only have it work with a 22ms frame rate?

Telemetry is only 22ms even in an 11ms system.

NEVER! There is always something to complain about!

Andy

Originally Posted by AndyKunz

Telemetry is only 22ms even in an 11ms system.

Telemetry may be 22ms but in an 11ms system, the control loop must execute within that time frame. Limiting the frame rate would free up compute cycles.

It is fine to get some insight on the things, thanks, Andy ! It is easier to understand why some features are not possible when you tell us the reasons.

We need more power . Let's overclock the CPU !

Originally Posted by AndyKunz

Sorry, I saw it and forgot to reply earlier. It's a technically-possible idea, and I designed that into the radio from day 1. A decision to think about going that route is way above my pay grade.



Databases are far more expensive in time and memory!!! You have to add the duration of the normal write stuff (that already takes too long) to the database system's overhead.

It's not even being written to a text file, it's the pure binary data off the air. There's no write, dump, ... sequence - it's a matter of write, write, write... to buffer until sector full then flush to disk, write...to buffer until sector full then flush to disk, ... until allocation unit full then read directory sectors, allocate more AU's to the file and flush the updated directory sectors to disk, then start to write, write, write... data again.

The thing that takes most time, especially with a card that has files on it already, is what happens when an allocation unit needs to be added to the file. Sometimes the file system needs to read (and write) multiple directory sectors, and those take time.

Believe me, there's nobody who wants data logging in the DX8 more than me. If I could have slipped it in unnoticed, I probably would have!

Andy

Write to onboard memory instead of disk ? Or some other media that would be faster and could handle it better. Then download to disk later.

Just thinkin out loud man. Gotta be a way with fewer man days.

Originally Posted by FlyHighSelllow

Write to onboard memory instead of disk ? Or some other media that would be faster and could handle it better. Then download to disk later.

Just thinkin out loud man. Gotta be a way with fewer man days.

I have no understanding of the limitations. But,
What about only recording data every 5 seconds (to pick a radom number).
Or
only recording a couple of sensors that are user selected.
Or
record one or two at a time and cycle through all
Or
how about just recording the top 20 max/mins.
You get the idea, limit the amount of data, the data rate.....

Just throwing it out there, I don't even use the telemtry at this point.
I have never had any issues with the radio and it does everything that I thought it would when I bought it.

At this point I am reading between the lines and if telemetry logging has been in since day one and we still don't have it I would highly doubt we are ever going to get it, no matter how hard Andy tries due to the CPU limitation that the 10t apparently fixes. Thanks for the info that you have given.


I am really dissapointed at this point.

maybe jumping to DB access might solve the prob.
I was doing Computer programming some years ago and I understand Andy completely.. Sometimes computers act weird.. and sometimes you need to ho a whole other way to achieve the same thing.
Give the guy a brake. I'm sure he will figure it out at somepoint

That's why I am waiting for the next JR radio - it will be done right.

Originally Posted by stgdz

At this point I am reading between the lines and if telemetry logging has been in since day one and we still don't have it I would highly doubt we are ever going to get it, no matter how hard Andy tries due to the CPU limitation that the 10t apparently fixes.


I am really dissapointed at this point.

Andy, thanks for giving us some insight into the limitations of the radio and why logging hasn't been done. Your latest string of messages has added a lot of value to this thread.