Buy an Axon, Axon II, or Axon Mote and build a great robot, while helping to support SoR.
0 Members and 1 Guest are viewing this topic.
The ZIP file is here: http://stoiadan.ro/portdump.zip
cosminprund, turns out I'm a moron . . . the DAQ prints out 18 values, where the last two represent the timer. Could that be why it didn't work?
I'm pretty sure this is ether the SparkFun module complaining about frame errors, my Edimax BlueTooth dongle OR my AVR software! I'm pretty sure it's not by Delphi software and I hope it's my AVR software because that's easiest to fix.
I still want to know if this works with the Axon DAQ as it is right now, I assume it does. My next mission is to start make this configurable, but that's for the next Weekend!
Bad news is when I clicked 'Bulk I/O' and then checked the box. It immediately crashed/blew up the program. Since data is coming in insanely fast anyway, maybe it should be limited to one line per 250ms or something like that?
Do you know how to show the data as a line graph? Perhaps make it look like an oscilloscope (sensor voltage vs time)?
1) [...]2) [...]2a) [...]
3) Add a 'Pause Signal' button for the charts - basically just stop updating the line chart so that the user can have a close look at the signal until he hits 'Resume'.
4) [...]5) [...]6) A new program name/icon. Like 'Axon Oscilloscope' or something like that. Got an icon with oscilloscope zig-zag lines?
Feature Creep ideas:Set these to lower priority unless you consider them very easy . . . but I'm dreaming of options such as 'report max value', 'report min value', 'report average value', data smoothing, print waveform (with a printer), save waveform as .png, and even the ability to overlay several channels in different colors on the same chart.
One idea I have is a 'user scaling equation'. So lets say a person has an equation for a Sharp IR that relates voltage to distance, he just types it into a box and the graph modifies itself somehow to display distance and not voltage.
If the sensor value gets stuck on "0" or "255" for longer then 1 second enter auto-pause mode and resume recording only when I start getting other values.
I'm aiming more towards "SoR Oscilloscope" if you like that. The idea's that I want this to work with anything outthere, not only the Axon.
"report max/min/average value" - you want those on the graph or in a corner somewhere?
That's interesting. Would you mind showing me some equation variants? What would be the preferred notation?
so the insanely fast "DAQ" with the very strict format is not very useful
Here's what I'm thinking of: I want to be able to use this little software for other things too (ex: for robots that actually run around the house) - so the insanely fast "DAQ" with the very strict format is not very usefull. I'd like to add commands for updating an arbitrary number of sensors at one time AND for sending status code and text comments. I imagine a GUI that can be configured to look like a dashboard with a number of different kinds of sensors plus a little text box (similar to how the "bulk data" box works) that displays comments sent from the MCU.
so I'd be able to declare the first version complete and send it out into the world
Quoteso the insanely fast "DAQ" with the very strict format is not very usefulIf your graph shows pixels per millisecond, I need to make it much faster to view servo PWM (one pixel per 100us). I'm going to try and speed it up. Or maybe make a second DAQ program that only prints one ADC (since USB is the bottle neck).
The "backend" that stores data to be shown on the graph has a resolution of 1 millisecond. Happily that resolution is configurable via a constant. What should be the resolution for the backend? Help me do some math here, to figure out how much the GUI should expect.The Atmega640 says:Up to 76.9 kSPS (Up to 15 kSPS at Maximum Resolution)Going on the highest number, 76.9 kSPS per second, that requires a serial transfer speed of 692.1 kbits/sec (76.9 * 9) - Is the Axon capable of pumping that much data over the USB line?
About the math: as an extreme-case scenario, let's assume the Axon is only sampling one analog input pin and it's dumping the result straight into the USART! No conversion, binary data is just fine and makes good use of every single bit
uart2SendByte(a9);uart2SendByte(what is a carriage return as a byte?);
Code: [Select]uart2SendByte(a9);uart2SendByte(what is a carriage return as a byte?);
// Init the UART // Init the ADC // Start the first ADC conversion while (1) { // Wait until the USART is ready to receive an other char while((UCSR0A & Bit5) == 0); // Send the result of the last ADC conversion UDR0 = ADCH; // Init the next ADC conversion ADCSRA |= Bit6; }
QuoteI wish I was better at Java programming I got to learn that 'swing' library so I can make Java GUIsThe gui's arent the problem in java for this issue...The problem is that Sun removed their comm api for windows and everything else apart from solaris x86 and some high level linux type meaning that there is no support for serial communications.....(I still have an old version of the comm api and libraries so im gonna see if it works with my xp system, if so i might release a simple terminal program for other people to test on their systems).
I wish I was better at Java programming I got to learn that 'swing' library so I can make Java GUIs
Any source code available?
(2) Shows data rate in kylobytes per second: how much data is pouring into the application from the serial port or the "function generator"
It was going at about 10.3 kbps with axon_DAQ.hex. I noticed it was taking a running average, so its a bit slow in displaying the correct bit rate. Can you speed that up?
Some minor bugs I've noticed. In the graphed data, on the far left, the curve spasses just before it goes off screen on the left.
The green lines also get freaky and jump around at particular Time Base selections.
And this will probably not be easy so don't worry about it . . . it'd be nice to use the mouse to zoom into a selection on the graph. Either by using the scroll wheel on the mouse, or by drawing a selection box, for zooming in. Yea, feature creep
Dumb question: what' "spasses"? Google doesn't know the word and I'm not an native English speaker.
This could be fixed by only updating the graphic once-per-time-base: If you're looking at an graph that has a timebase of two seconds it makes little sense updating it 50 times per second as it happens right now Smiley In my opinion this fix is not worth the trouble.
Here's my to-do list:*) Make an File menu with "Save data" and "Load data" options; This would help with development.*) Implement an expression evaluator so I can "translate" graph data*) Implement auto-scale in the graph window as well as configurable scale*) Make it so I can show more then one graph in the same window*) Implement pauses and auto-pauses;
*) Make an File menu with "Save data" and "Load data" options; This would help with development.