Hexadecimal String To Number conversion

[wiebe@CARYA]

---

@crossrulz wrote:

---

wiebe@CARYA wrote:
Start and stop signatures are also an option, but also just make communication failure less likely.

---

That is all that these communications schemes actually do: make failure less likely. 

---

Well, also recovering communication if (when) communication failed. Although perhaps that is a subset of making failure less likely.

With a binary streams recovering will usually work out (by looking for expected patterns).

With end termination characters (that can't occur in the data) or 2 way communication recovering is a lot easier.

[crossrulz]

---

wiebe@CARYA wrote:

With end termination characters (that can't occur in the data) or 2 way communication recovering is a lot easier.

---

I fully agree that ASCII protocols (with the termination character) are easier to deal with, especially on the read side with VISA.  Most importantly, it is a lot easier to debug since you are dealing with text instead of random bytes.  But you do lose accuracy unless you use a lot of characters.

A 2-way may be a good idea to start the stream (have the PC tell the STM32 to start the data stream and when to stop).

[wiebe@CARYA]

---

@crossrulz wrote:

---

wiebe@CARYA wrote:

With end termination characters (that can't occur in the data) or 2 way communication recovering is a lot easier.

---

I fully agree that ASCII protocols (with the termination character) are easier to deal with, especially on the read side with VISA.  Most importantly, it is a lot easier to debug since you are dealing with text instead of random bytes.  But you do lose accuracy unless you use a lot of characters.

A 2-way may be a good idea to start the stream (have the PC tell the STM32 to start the data stream and when to stop).

---

You can always send the float's flattened bytes encoded as hex strings of course 😁.

[giomarinna]

wiebe@CARYA so you're recommending me to convert my data in string and then send it?

@crossrulz I still have a problem with the Unflatten From String.

If I put a constant string input, as you showed, it works.

If I continuously send messages from stm32 in input (referred to the scheme below) it works.

But if I stop to sending data from the stm32 leaving the COM open, it return me this error. What I'm doing wrong?

 

[JimB.]

You're trying to unflatten an empty string. You should only perform the conversion when you have read in data. (And you should put in checks for your start value to make sure you have all bytes in the correct order.)

I'm away from a computer I can test on, but I'm pretty sure if you tried to reproduce that with a constant input that you would get the same error for an empty string input. Probably for any other input of less than 6 bytes (the size of your cluster containing 3 16-bit values) as well.

[crossrulz]

---

@giomarinna wrote:

What I'm doing wrong? 

---

You are still using the Bytes At Port to tell the VISA Read how many bytes to read.  That is a major issue.  You really need to better define your protocol.  Did you watch the video I linked to before?

Also, if you change the byte order to Little Endian at the Unflatten From String, you will not need to use the Swap Bytes.

[giomarinna]

I watched your video, now I'm trying to improve my project.

I insert a constant with 2 value because I expect 2 byte message. 

From my nucleo board I'm sending this message {0x00AA, 0x0000, 0xFFFF}, element by element.

The Unflatten From String still return me that error.

 

[crossrulz]

---

@giomarinna wrote:

I insert a constant with 2 value because I expect 2 byte message. 

From my nucleo board I'm sending this message {0x00AA, 0x0000, 0xFFFF}, element by element. 

---

Your message is actually 6 bytes long.  So you should be reading 6 bytes.

[giomarinna]

I worked hard and I improved my code but there is one last problem.

I'm sendind this message from my stm32: {0x00AA, 0x0000, 0x98FE, 0x98F9, 0x9919, 0x98F1, 0x9900, 0x98E5, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF}; where 0x00AA is the start and then all the info I want to transmit.

These info needs to be processed and this process have sense only if the vector is readed in the correct order: starting from 0x00AA (you will see AA00 into the attached screenshot because transmission swaps the bytes).

The problem is that sometimes on labview the vector is received not in the correct order. I tryed to solve this problem continuously sending the vector from my stm32 whilst a 19 value in not sent from labview to my stm32.

The drowback is that sometimes this "syncronizzation" require lots of attempts.

I can't understan why labview do not receive the message in the correct order. If I try to send the same message to a classic termial connected to the COM, the vector is always received in the correct way. Any advise?

I attach some screenshot which allow you to better understand.

   

[crossrulz · Accepted solution]

I'm not understanding why you are trying to read 32 bytes when searching for your start word.  My original suggestion was to just use 1 byte as your start byte.  If you are going with a start word (2 bytes), then you need an extra step.  Read 1 byte at a time until the 0xAA is read.  Then read 1 byte and verify it is 0x00.  If the verifcation passed, then you can read the rest of the message (30 bytes).

You also do not need the VISA Clear if you use this synchronization method.