"^ECHOF 1" problem with ttl microcontroller comunication

hello, i\'m using a micro-controller to send and read commands from my SDC2130-S controller.
when ECHOF is set to 0, everything works great, i can send command and queries and read the echos.
when i turn the echo off (^ECHOF 1) and then try to send commands nothing happens and the controller echo junk.
i noticed that when a script is running i can read its printings well.
when using the roborun+ program with usb connection i can turn off the echo with no problems.
here is an example of the controller echos before and after the echo off command:
\"
!g 100
+
!g 200
+
?c
C=290860:0
^ECHOF 1
+
kkkkkkk‚kkkkk‚‚kkkkk
\"
my goal is to control my motor with my micro-conroller without getting commands acknowledgements. i want only to transmit a specific data from the controller to the mc.
can anyone help with this problem please?

thank you,
Yam Geva

Echo off is practically never used by anyone. We\'ll verify that it works.

In any case, echo off would not eliminate the + and - acknowledgement. It would only eliminate the controller from sending back every character it receives.

For your application, you may find it just as simple to ignore the echoed characters.

Was there any resolution to this question?

I'm having intermittent success using the ^ECHOF 1 command with SDC2130s. When it fails, it just echoes the ^ECHOF, even if I send the command multiple times in a row with 1 second delays in between. It's important for me because I'm struggling to cope with the SDC2130's extremely unreliabe serial communication. Simplifying and reducing the communication is helping, when it can be relied upon.

Thanks,
- ac

The serial communication on all of our controllers is very robust. If your connection to the serial line is flakey, this would cause the Echo function to not work or work intermittently. You'll need to check your serial lines. Are you connected to the serial port directly to the pc, or are you using a serial to USB converter?

Try making the echo off part of the stored configuration. Send ^echof 1 followed by %eesav.

Thanks. The %eesav has solved the problem with ^ECHO 1.

But I'm still spending days trying to get reliable serial communication. My setup may be unusual: 8 SDC2130s connected to one Ubuntu 13.04 computer and 12 connected to another.

One error condition I'm seeing at the OS level, with SDC2130s spontaneously disappearing and reappearing with new, incremented names in the /dev directory. I'm still swapping out hubs to see if it helps. But I mention it here in case anyone here as encountered and resolved this already.

In the second error condition, all SDC2130s are present and communicating, except one or two will suddenly stop responding. I've been trying many tricks, like tweaking the delays between tx and rx, flushing at times that shouldn't be necessary, adjusting timeouts and the number of bytes read, looping retries anywhere they might do some good. But it looks like they're just not responding. It's resolved by power cycling the unresponsive SDC2130. But that's not an option in production environments.

If you have any insight into this it would be very helpful.

- thanks

Perhaps you might want to consult with Ubuntu, Canonical, or perhaps the Linux community. Also, is this the latest distro. of Ubuntu out there? Maybe try another updated version if possible?

If the device is mounted to the O/S, is that done through a terminal command, or is this auto-recognized similar to that of a say an external hard drive?

Okay, not sure if you have already done so, but have you already downloaded our Linux API?

dev.roboteq.com/dev1/index.php/support/downloads

From the Ubuntu search, it came up with serial console, which I imagine you are probably using.
apps.ubuntu.com/cat/applications/raring/gtkterm/

Thanks for your response, Griffin,
Yes, Linux mounts serial devices automatically. Like a hard drive, as you say. And it assigns all devices file handles in the /dev directory. I've been using it since 2008, when I found everyone at MIT considered it the bedrock OS for talking to hardware. The only comm problems I've encountered in 5 years have been with these SDC2130s. In fact, I'm currently using the same hardware/os/software to talk to a network of 21 Arduinos. No such issues there. It was even fine with my homebrew UARTs made with FPGAs.

Thanks for the tip about gtkterm. I've now been using it for testing. But unfortunately, I'm seeing the exact same comm issues as with Python. Once an SDC2130 stops responding, which seems to be 10% likely within 10 minutes, I cannot get a response out of it with my code or gtkterm. A power cycle of the SDC2130 solves it most of the time.

I've bought and swapped out a few different USB hubs. But it was unnecessary, as I've now seen the issue happening just as frequently with no USB hub in the way, just a USB cable.

I've looked through the Linux API code. But it does seem to wrap the exact same OS methods that gtkterm and pySerial wrap. So my faith is low. But I'll try anything at this point that enables us to get over this impasse and back into development.

I see a warning in the nxtgen documentation that implies that USB<->serial communication may be vulnerable to problems that can be solved by switching to the rx/tx on the IO connector. But I don't see much about it in the forums. I'd be happy to buy 20 ports of industrial RS232 and rewire/resolder all of the IO cables to add serial if it would solve these comm issues. But it's a big time investment and I'd like to know up front if issues like this have been resolved that way in the past.

- thanks again

For customers issue with the communication with our controllers with the USB as the primary use for communication, they reported back that their communication problems they were having were eliminated using the serial Tx and Rx lines. Give it a go on one or more units and see if you get the same problem. The USB was determined as not the most suitable for application use as there are various factors that could cause communication loss such as a loose connection, intermittent connection, and other various other conditions which may not have yet surfaced.

We recommend that customers use the serial communications lines through the RS232 Tx and Rx.

If you're setup doesn't have a serial port on the back of the PC, you can always use a serial to USB converter. One I wouold recommend as they do work with Linux.

www.usconverters.com/usb-serial-converter-anu232std

I seem to have some resolution of this as of today. I noticed that the main trouble was coming from two of the eight SDC2130s. I swapped them out with brand new ones. And now everything seems to work.

These two may be part of a batch I encountered this summer with poor [cold?] solder joints in the USB connector. I know it was poor solder b/c they popped off at the slightest provocation.

This resolves the issue of non-responsiveness on startup.

I still see the controllers disappearing and being re-added by the OS. But hopefully I'll get some resolution by changing the comms from the USB connector to the IO connector, as suggested in the warning on page 113 of the nexgen documentation.

I'll write back with info when this is resolved. Thanks for your help.