[SOLVED]Cubecell serial USB - data limit?

#1

I cannot get the cubecell to read more than say 7 integers at a time. For this test I created a simple sketch to serial.read on my cubecell, i.e. “while serial available ( serial.read…into a char array)…add ‘/0’ at the end and serial.println…” - I use this method on many of my projects, works perfectly…except on my cubecell. Then I connected my cubecell via USB to my computer. I opened the serial screen and type a bunch of numbers i.e. 1234567890, simple enough right? But after the ‘While Loop’ is exited the serial.println output of the array only shows the first 7 or so integers correctly. I set the serial timeout down from 1000ms to 10ms and tried again with no better results. I get slightly better results if I add a slight delay to my “while available serial.read loop…”. I also tried setting the baud rate to 9600-115200 with no better results, with or without the delay, and also tried with a higher and lower timeout threshold. If I load this same sketch to my Heltec ESP32 Oled board I get flawless results. Any ideas why the cubecell can’t take more than 7 integers per serial read?

#2

Can you paste your code of the serial reading part? In out AT commands example, CubeCell can read sentence like: AT+AppSKey=00000000000000000000000000000000

#3

I am not using AT commands. I am simply typing in the serial window to a Cubecell connected to my computer via USB cable.

I am doing this test to debug an issue I am having sending data via USB serial communication from a teensy LC connected to the Cubecell via male to male USB OTG cable. The teensy LC has 5 touch sensors, a temperature sensor, and a homemade NE555 capacitance sensor I built.

rough diagram below
TEENSY LC ==>—USB OTG Male to Male cable—<== Cubecell
shared NEG/ground.

example data sent via USB serial
1,25000,25000,25000,25000,25000,98.6,4000000

As a result of this test I see the cubecell cannot handle my entire string
i.e. serial send via usb from teensy LC touch sensors

Below is the code I execute in Loop{ check_serialC(); }

void setup(){
Serial.begin (115200);
}

void check_serialC()
{
if ( Serial.available())
{
char serialResponse[254];
int i = 0;
while (Serial.available())
{
serialResponse[i] = (char)Serial.read();
i++;
//delay(1);
}

serialResponse[i] = '\0';
Serial.print("HERE IS RAW DATA:");
Serial.println(serialResponse);

}

#4

You have to use at commands, because the serial is limited to that.
Have a look at the at commands example.

Creating an own commands is simple.
Your teensy can than send the data as at commands and you can handle the data in the cubecell.

#5

Great! Thanks for the follow up. I will try the AT comm to Cubecell.

#6

I made some progress using the commands below:
AT+LORAWAN=0
AT+SendStr=abcdefgh

output below
ASR is Waked,LowPower Mode Stopped
+OK
+Send String:abcdefgh
TX done

#7

AT+SendStr=25000,25000,25000,25000,25000,100.99,4000000
+OK
+Send String:25000,25000,25000,25000,25000,100.99,4000000
TX done

#8

I just need to figure out how to save these into a data struct on the cubecell.

#9

Hi, @jnevins, @rsmedia

I think we all made a mistake, in the Jnevins’ example code. CubeCell will print a char when the buffer received data, but receiver buffer is faster than printing. As more data is received, more time is spent printing… it results the serial port can’t receive data anymore.

Aaron had fixed the bug in the source code, please use git pull to update your framework, and refer to this simple example, hope it can make sense to you:

void setup() {
  // put your setup code here, to run once:
  Serial.begin (115200);
}

void check_serialC()
{
  if ( Serial.available())
  {
    char serialResponse[254];
    int i = 0;
    while (Serial.available()&&i<253)
    {
      serialResponse[i] = (char)Serial.read();
      i++; 
    }
    serialResponse[i] = '\0';
    Serial.print("HERE IS RAW DATA:");
    Serial.println(serialResponse);
  }
}
void loop() {
  // put your main code here, to run repeatedly:
  check_serialC();
}
#10

Thanks! I will update the framework and try again, with the i<253 added for good measure.

Cubecell USB Comms
#11

okay ready for this? I rebuilt my enitre framework and loaded the sketch and it didn’t change my results. HOWEVER… lower the baud to 1200 and add a delay(9) and it works!
TEST 1 )
open serial monitor and type 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456790
HERE IS RAW DATA:
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456790

Below is the sketch I used. I started my testing using the &&i<253 in prior replay but once I worked out the baud and delay I removed need the added check.

void setup() {
// put your setup code here, to run once:
Serial.begin(1200);
}

void check_serialC()
{
if ( Serial.available())
{
char serialResponse[254];
int i = 0;
while (Serial.available())
{
serialResponse[i] = (char)Serial.read();
i++;
delay(9);
}
serialResponse[i] = ‘\0’;
Serial.print(“HERE IS RAW DATA:”);
Serial.println(serialResponse);
}
}
void loop() {
// put your main code here, to run repeatedly:
check_serialC();
}

#12

FYI just tested on another cubecell and it also works. The serial data is now being read correctly in the right sequence as typed.

#13

We can assign this topic [Solved] now?

#14

sure please close this, thanks!

#15

Hello

unfortunately, this topic should be opened again!
This code only runs if you do not add any other code line in the loop(), e.g.:

void loop() {
  // put your main code here, to run repeatedly:
  delay(10);
  check_serialC();

}

I added only a delay of 10 ms and characters were lost. If I add more code, only 8 characters will be received via the on-board serial link (UART). I’m using the CubeCell HTCC AB01.

I really tried a lot to make this serial read function run together with some other code, e.g. I used a scheduler (compare with millis() instead of using delay()) or I called the check_serialC in a repeat loop or I put the while (Serial.available()) into a repeat loop. Nothing helped.

Besides that, it is no satisfying that the baud rate needs to be decreased to 1200 Baud.

Heltec showed, that somehow ther must be a possibility to receive more than 8 characters reliable: look at the AT-Commands. Why can’t we use this technic in the serial read function for user applications?

I hope anyone can help me.

Greetings,
Äd