this works for my purpose as well, with 1 caveat: it can only search the first sheet in an excel sheet. is there any way to get this to look through multiple sheets, and return the row and sheet name in 2 different variabvles? I have included an example sheet here.

이 댓글에 대한 바로 가기 링크

I've moved along in my code, and this code has stopped working properly. i have appended the new code here. instead of a user input, this code takes data from serial, and uses it to find the excel sheet. It doesn't get the correct sheet or row.

이 댓글에 대한 바로 가기 링크

The configured terminator would signal end of line. It would be removed from what is returned to the user, and whatever else was received after would be left in the buffer, not to be returned until another read call and another % received.

If you have cr/lf those almost always represent end of the unit for processing purposes and should be the terminator.

There are some uncommon cases with binary data where cr or lf are data and something else like SOH (0x01, control-A) marks a processing boundary

이 댓글에 대한 바로 가기 링크

Is that potentially why I am getting weird Unicode in my tags? Other places in my code I use fscanf on serial(), and my tags scan fine. Is there some kind of issue with readline() where the tags get scanned incorrectly sometimes?

이 댓글에 대한 바로 가기 링크

If your stream includes characters with position beyond 255 then I would recommend using fread() and native2unicode or unicode2native.

If your stream contains bytes with the first two bits set then if you were reading in a mode that expected text and the encoding were not configured otherwise, then potentially the bytes could be understood as introducing a utf8 sequence. If the first bit is set but not the second then that could be a continuation byte in utf8 but the implementation would have to be broken for utf8 to be triggered without an introducer byte with both first two bits set.

... Basically if you have bytes above 7f then be sure to configure the translation mode, or else use fread and do the translation yourself.

I would need to review the serial() and serialport() settings to control multibyte translation.

이 댓글에 대한 바로 가기 링크

That might be the issue. First couple bytes sent are set, so I'll try setting it to read as a character to attempt to translate properly. If that doesn't work, could I post the files so you can take a look?

이 댓글에 대한 바로 가기 링크

EDIT: I was able to find a fix for the code, just replaced a different variable type, and got rid of some of the concatonations. I noticed that nearly all the weird unicode gibberish occurs where a ) should be on the of a tag. It very rarely happens with any other number.

이 댓글에 대한 바로 가기 링크

Well, that is a bit strange. ETX, %, EOT, EOF, CR . It's like someone wanted to be really sure that the line terminator was received.

I suggest you experiment with

regexp(deciding_data, '[ -~]+', 'match', 'once')

which will only match characters from space (32) to ~ (126) . That excludes newline (10) and carriage return (13) and ETX (3) and EOT (4) and EOF (26). Note that the % will get trimemd by this, as it is after the first character in the range 0 to 31 .

이 댓글에 대한 바로 가기 링크

By the way, I happened to notice that the documentation for readline() for serialport() objects specifically says "Read line of ASCII string data from serial port". That implies no Unicode translation is taking place.

이 댓글에 대한 바로 가기 링크

That's very odd, and possibly explains why I am getting those incorrect reads. One problem I foresee is that the tags sometimes scans in with the ETX before the %, and sometimes scans with a zero. I don't know exactly why a zero replaces the ETX, (or why etx replaces a 0). Is there a way around that? As in, make the search code work whether there is an etx or zero in that space? Alternatively, since each tag ends with a 0% (or maybe an etx%), I can just trim off any trailing zeros.

이 댓글에 대한 바로 가기 링크

Unless you need the % to distinguish something then use the regexp match that I posted to extract the initial string of printable characters and ignore what is after. You might still need to trim off the % if you happen to receive a packet with no binary garbage. If % is not valid earlier in the string you can adjust the pattern I posted to '[ -$&-~]'

이 댓글에 대한 바로 가기 링크

That fix seems to be working. By trimming off any weird Unicode as well as the 0 and % off of everything. It all seems to be working for now, I just need to change some indices lengths for the new shorter code. Thanks for all the help with this