I have been working with your MDEK1001 development kit as part of a project employing your tracking system at my university. However, when attempting to communicate with the kit via UART, I am always faced with an unreliable initialization process that involves spamming of the enter key. The issue is that I have so far failed to discover the correct pattern (if any) of enter commands to reliably initialize the system automatically. This is possible manually using an arbitrary number of opens + closures of a terminal program. I have used both Tera Term and Putty to attempt this manual initialization but continue to fail in finding a consistent solution.
Here is what I try in (Python) code, which employs the Serial library:
while tryInit:
ser.write(b’\n’)
countTries += 1
dataBuf = []
while ser.inWaiting():
data = ser.read()
dataBuf.append(data.decode())
returnStr = ''.join(dataBuf)
print(returnStr)
if "dwm>" in returnStr:
tryInit = False
# Send command 'lep' and return key to start the data collection
ser.write(b"lep")
ser.write(b"\n")
However, I am faced with the issue of failed initialization. The only way I can get this code to not constantly loop at the @ sign is to manually attempt initialization through the terminal, which in itself is not a reliable solution due to the uncertainty in the number of enter clicks involved.
I figured out from the API documentation that I need 2 return carriage characters to be able to initialise the command line reliably. However, I am still trying to figure this out in code (Python) as two different commands with a small delay using the Serial library send command function does not seem to simulate the same thing as my manual clicks on Putty.
Do you know any shortcuts that I can use? If not I will have a look elsewhere.
If i remember correctly, whenever I tried to double press enter to start inputting commands/stopping a command, i had to press it very quickly. So maybe adding a delay for the enter key might not be a good idea. Other than that I am not sure how I can help.
Are you using windows and a USB-Serial adaptor?
If so the drivers can try to be smart and to group commands together which can have a big impact if the timing of the commands is important for your application.
Depending on the type of adaptor used there may be a way to improve this.
e.g. on FTDI chip based USB serial devices you can find the port in device manager and select properties, port settings, advanced.
If you then decrease the buffer sizes and latency timer you can get far more control over the data timing at the expense of increased processor loading. But serial ports are painfully slow, if your processor/application can’t cope with the increased load then you are doing something very very wrong.
I can’t see why this would be a problem and why you can’t just send a two byte array of 0x0a 0x0a on the serial port if you need two enters in a row but it doesn’t hurt to check.
I have managed to get it working! Turns out I needed to send a single return command, insert a small delay and then send another single return command like so:
ser.write(b’\r’)
time.sleep(0.1)
ser.write(b’\r’)
My previous attempts involved sending the \n and \r\n commands which resulted in the issues I had been facing. Thank you both for the insight!
