I have forked the original code repo and made the changes as per trevorshannons suggestions. Still in the process of testing to see if the problem is fully resolved. Feel free to improve things further.

https://github.com/archfiend/Serial-Accelerometer-Dongle

Would there be any reason why I wouldn't be able to send the data through a blue tooth module?

Hello,i bought the accelerometer few days ago.My controller has UARTS (only with rx tx and gnd connectios).So i externally applied vcc and gnd.The accelerometer got powered ON still am not able to receive any data on UART.Can someone help me please?

hello , i bought the accelerometer few days ago , but i tried to get the information on hyperterminal but it doesnt work . it gives me (ySN)ëÒÛSÂ) the accelerometer takes power from the serial port as they sad before . can someone help me please ?

i didn't see enough noise to make this 'unusable' but i did see some strange jumps every once in a while. for example, for one sample, x would increase a lot while z would simultaneously decrease a lot. suspicious...

taking into account what others have already mentioned, i made the following change to the firmware (sorry for pseudo code) and i seem to have eliminated those random jumps.

ISR(ADC_vect){
 cli();
 if (!channelChanged){
  do the normal ADC_vect
  channelChanged = true;
 }
 else{
  store ADCL and ADCH in a temporary variable
  channelChanged = false;
 }
 sei();
}

An update on where I am with respect to the glitch affecting the ADC output. I haven't been successful in updating the firmware, I get an error from adrdude "avrdude: stk500_getsync(): not in sync: resp=0x1c" (with a different resp= number depending on the baud rate). This seems to be a common problem, but I haven't been able to find a fix. I'm not sure if http://www.arduino.cc/playground/Code/MegaISP is relevant at all - I did try patching avrdude with a delay and various combinations with pressing the reset button, but no success. I'm not going to try fiddling with the reset lines on the dongle unless I get positive confirmation that this would fix my problem. I've ordered a pocket AVR programmer so I'll see if I can use that instead.

On the firmware bug, if I understand Etienne and the datasheets properly, the problem is that in free-running mode the ADC conversions occur at quite rapid intervals and it is possible that an ADC conversion can happen while ADC_vect is still executing, before the ADC channel is updated. Therefore, as soon as ADC_vect reenables interrupts it gets called again but with the ADC reading from the wrong channel. In the datasheet for the ADC at http://www.atmel.com/Images/doc8444.pdf there is a note "It is recommended to discard the first conversion result (like whenever there is a change in ADC configuration like voltage reference / ADC channel change)", which suggests that when the channel is changed we should discard the next reading from the ADC anyway. I've modified the firmware to do this, but I can't try it out until I can find a way of loading the firmware.

Also, looking at the firmware I am not sure if there is another problem: when calculating the average values in the sensorADCCount variable, free-running mode is disabled but as far as I can tell this doesn't disable interrupts (contrary to the comment in the code?), so is it possible that there is one more interrupt still pending when it enters the loop? This might be harmless, if the update to adcReading is atomic(?). But I'm curious as to why the change to the free-running mode, rather than simply disabling interrupts while calculating the sensorADCCount.

Hi ryowen84,

The ADC_vect routine in the firmware code has a minor glitch with very visible consequences Glitch: When the ADC finishes reading a value (on channel X for example), and ADC_vect is already executing (for a previous reading on the same channel), the interrupt raised by the ADC is put on hold until the end of the routine. Then the routine is executed again for the new value, which gets saved into the next channel (say channel Y). and the second value read for channel X is saved into a different channel. Consequence: Readings from one channel are saved to another channel. This creates unacceptable noise

Do you have time to solve this, or do you want a patch ? It's just adding a variable ADC_vect_running, set to true inside ADC_vect, then adding "sei" and "cli" instructions to let the new interrupt trigger the routine and have a check at the beginning of the routine to exit if ADC_vect_running is set already.

Etienne email: etilegr, hotmail, com

I bought 3 of these, and planning to buy more, to support an upcoming STEM activity, but... I'm finding a huge amount of noise on the data outputs. It seems like the X,Y, and Z channels get mixed up a lot. When it works, it is great, but in an overnight test, roughly 50% of the data was garbage. The github Wiki gives the source code and mentions that it can be reprogrammed easily using an Arduino programmer. And if I can reprogram it, I can debug the issue and move on. But, I've failed so far at reprogramming it. I've tried using both the Arduino Development Environment and WinAVR (I'm new to both of them), but in both cases avrdude never successfully connects. Has anyone successfully reprogrammed this device? If so, can you tell me what "avrdude" settings I should be using? (Seriously, this is for STEM... It's for the kids!)

Can you connect this to a C# GUI to just read out the accelerometer data without having to do anything special like control the menu from C#? Or do you have to use this with a terminal program?

Is there any source code available for this?

Thanks

Set your baud rate to 38400, then you can see the menu and set the BR to what you want.
Is there any other documentation for this?

UPDATE: resolved
"Hi Christopher
Through my fiddling I have found that the baud rate on my dongle was set to 38400 and thus this is what was causing the problems"
ISSUE from a customer:
I recently Purchased a SEN-10537 and con not get any readable output from the
device it just comes out as garbage
I am using the following settings in hyper terminal
9600,8,none,1 with no flow control
The dongle is being connected via a usb to serial cable
IS there any know issues with the dongle ?
And what can I do to get the dongle working on my pc ?

There seems to be a little design flaw with the DTR pin being capacitively coupled with the Reset signal.
DTR can go from +12V to -12V and create high voltage/current transients.
Since the RS232 pins drive is not very strong, it should work most of the times, but if DTR is directly tied to -12V, the 0.1uF capacitor will have to discharge through the processor (not very likely as it would keep the processor in reset, but could be destructive). Since the reset pin is also used in Atmel "high voltage" programming, when +12V is applied, there is a possibility that transient voltage from DTR could send the processor in this programming mode, thus interfering with expected behaviour.
Connecting any unused pin to Reset would prevent the pin from going above 5V (There is an ESD protection diode on all signal pins except reset) and a serie resistor (1K seems good) would limit the capacitor charge/discharge current to a safe level.