My Dad can beat up your Dad … no, wait a minute, I got caught up in the current culture of this thread. Why don’t we all focus in providing Bure and associates the standards that we need in a file save?
Once again these standards already exist in the BenF firmware. Screen saves are good because they can include measurement values. Capture buffer data saves are good because they are virgin signal data. Each type of saved data file has it’s own merits.
I couldn’t program a file format to save my butt, however, BenF has already defined the required parameters that are needed to reconstruct his saved files. I would suggest that Bure and associates use whatever file format that is appropriate for the Quad, but also modify any such file format to include this additional header info that is required.
Excerpt from Nano v3.62 User Guide, BenF calls this header info a “Profile”:
No matter the format of the save file (direct captured data buffer (1/4 centered on trigger or total buffer options) is preferred by myself), this is the kind of info required for accurate waveform reconstruction.
As for screen saves, the current CSV just appears to be a substitute for the BMP file format, probably due to the limited storage space on the virtual SD card.
It appears to me that most of these file format issues are a direct result of inadequate virtual SD card memory size. Otherwise, BMP and XML would be a no-brainer.
A while back when the quad first emerged I did offer to consult with the firmware developers about what I thought was needed to make a truly portable export format. But like so many comments left here in the forums for the developers, relating to the quad, it fell on deaf ears.
I kept my nose out of the bandwidth problem because I am not qualified to comment on issues that I have no experience in but having written a client already for the nano I think I am well placed to offer advice and comment in this area.
Besides, that slight OT silliness was a light relief from the techno babble that seems to dominate sometimes
Look back at what I wrote: I never said your conclusions were wrong in anything except where you were so patently wrong, it was obscene. I have only been describing a possible interpretation of the data, not claiming it to [u]be the actual[/b] interpretation, until it could be tested with real data. But your need to be acknowledged and ego stroked seems to have missed that bit, and I wasn’t having anything of it. I wasn’t running to conjecture based on “screenshots”, as your proof of choice.
This is exactly what I’m talking about. If anyone is doing the berating here, it’s you. Dude, you think you know everything about everything. I never brought up “25 years” until you made the presumption about my own skills, so really it’s you who have made all the presumptions in this “debate”. I’m not even going to fix your glaring error in this paragraph because, frankly, it stands on its own.
“attack” as conjecture? Now I really know you don’t value the opinions of others. You must be great in a team environment. I don’t know how clearer I could have been in every response I wrote… it was an OPINION. You’re so desperate to hear validation that it’s sad, really.
Rather than have you continue to presume, I’ll clarify what I think: I don’t think you’re stupid; but I can see how your ego won’t stop interpreting “wrong” as “stupid”. I think you’re frequently dismissed because you make obvious errors in a frantic error to prove your superiority, and yet still insist you’re 100% right all the time. I don’t think you’ve clued into why people don’t think highly of this behavior. That’s why I don’t care to discuss things with you: it’s like talking to a brick wall, and largely unproductive.
Hey PommieZ I was thinking about our little OT debate and I found this on another forum and thought it might appeal to your sense of humour (I am sure you have one deep down somewhere)
“There are 10 kinds of people, those who know binary, and those who don’t”
That my friend is a matter that has a whole debate about it, we have the spec and then we have the findings of many talented people on this forum, unfortunately they do not concur.
That’s funny! I’ve never heard that one before. Are you sure you didn’t come up with that yourself? I’m less impressed. I’d have been more impressed if you claimed you were the one who coined it, “30 years ago” while hacking your “intel 6502”.
Your Mother wears combat boots … just trying to fit in here.
I continue to poke fun here because I was here once in the bandwidth thread.
My concern with the possibility that the current CSV file format may save screen pixel resolution is that much signal resolution will be lost with this file format method. For example, if the screen has 0-250 pixels (need room for the menu above) and if the four channels were divided equally, then only 60+ resolution bits would be available for each signal instead of 250 bits of resolution.
As I have suggested in earlier posts in this thread, the sample buffer should be the source for the file format (even if only a portion of the sample buffer) so we can at least get the 0-255 ADC 8-bits resolution (which is already lacking when compared to the Nano 14-bits of ADC resolution).
I do hope that Bure and associates gets this point, and adopts the sample buffer as the required file format source.
It’s likely that the same routines that they are using to save a .DAT or .BMP file (aka “screen dump”) use the same data to generate the (junkie) .CSV file. You’re not getting a real capture/sample buffer dump, only a dump of the display window.
And I don’t just mean the data is bunk, I mean that the structure of the file itself is badly executed: ie. you don’t put commas at the end of each line (which would imply some sort of 5th column)… and I don’t know about you, but all the CSVs from mine toss in random CR/^M characters and garbage like NULs at the end of the file.
I agree that Bure and company have taken the low road here, and I hope they will get back on the high road and let us save real data not just low resolution screen dumps.
Once again for “Bure and company”, we need real data in the file saves, data that can be relied upon as virgin captured data, not some watered down screen save; unless that screen save is an additional option beyond captured data saves.
By the way, Bure and company, you have done a really good job with the Quad design and price-point, so don’t think we are always negative about your work. We do appreciate the recent updates and also appreciate the change notes and the zip packages. When you get these user issues resolved, then the Quad will be a viable and successful tool.
Why don’t we all focus in providing Bure and associates the standards that we need in a file save?
