No announcement yet.

vise genie without library, Arduino serial.write

  • Filter
  • Time
  • Show
Clear All
new posts

  • vise genie without library, Arduino serial.write

    I'm working on a project for interfacing an 4d display on a car, trough CanOpen. One avr micro controller is respocible for recieving can Data and is sending this data over ttl UART (tx -> rx) to the next microcontroller for further processing. this latest microcontroller is a simple Atmega328PU Arduino compatible. its receiving can data on its RX pin, and sending data to the display with the TX pin.  the display in configured as vise genie using the Genie library was no option. so we want to do it manualy. I have made some basic test code, but when the display turns on, in the first second i got an change on my gauge. after that I got only weird looking figures. and the display hangs here is the code void setup() {   Serial.begin(115200); } void loop () {   byte bdiMes [] = {0x01, 0x0B, 0x01, 0x00, 0x0A, 0x01}; // as example Serial.write (bdiMes, sizeof(bdiMes)); }     what is the solution for sending data to objects an gauges manually ?   regards, Niels Popping hope someone could help me with this soon

  • #2
    You should have no problem talking to Genie Manually, you can always use GTX to 'initially' figure out what to send and the expected response.

    The main issue is probably 115200, it's not a good match between Picaso/Diablo and the Atmega328. 200000 baud is a good match, so perhaps the first thing to do is try that speed


    • #3
      I tried the baudrate of 200000, No diference, except after setting the baudrate, the arduino, had needed an hard reset, before it was reregonized with the computer.
      I've took an look at GTX, based on that and the manual, i've seen that the data looks like 0x01, 0x0B, 0x01, 0x00, 0x0A, 0x01,
      but when i tried sending that data over serial to the display. I still get an red cross in place of the gauge's, and the screen is showing weird meshed up stuff.
      when i tried the Genie librairy, the sketch wont loop, maybe because the RX pin of the arduino is used to receive CANOpen data from an other MCU, and the TX pin is used for sending data to the display.


      • #4
        A Red x is generally caused by an out of range value. 'weird meshed up stuff' is generally caused by sending a command to action a non-existent object.

        You really need to be able to check for the ACK coming back from the display, as otherwise you can overrun its input comms buffer and run into all sorts of issues (err, like maybe that's what's going on)

        Can you make a small video and attach your Genie and Arduino source?


        • #5
          I'm currently unaivailable to sent to whole code,
          I've done some research, and found out that I've received a lot of NAK from the display.
          I've found a way to send information to the display, but in the manual it says
          01 0B 01 00 64 6F, with means write to coolgauge 1, value 100,
          if I want to add more gauges, the LSB value is other than expected .

          for example Set Gauge Value 12:02:44.541 [01 0B 01 00 14 1F] // gauge 1 at 20
          ACK 12:02:44.588 [06]
          Set Gauge Value 12:02:56.288 [01 0B 02 00 14 1C] //gauge 2 at 20
          ACK 12:02:56.304 [06]
          Set Gauge Value 12:03:12.902 [01 0B 01 00 0A 01] // gauge 1 at 10
          ACK 12:03:12.949 [06]
          Set Gauge Value 12:03:14.025 [01 0B 02 00 0A 02] // gauge 2 at 10
          ACK 12:03:14.072 [06]

          .If we look at LSB value, at 10, it increases with the other gauge, by one.
          at value 20 it increases 3 steps at gauge 2.
          while MSB is still the same, What kind of logic is behind this, and how do I know which value LSB is ?


          • #6
            Umm, I presume the red and green mostly comes from GTX, you've. just added comments?

            In your text you talk about a cool gauge, but the GTX text and the GTX object ID is for a normal Gauge, not a cool gauge.

            I'm not sure that I get what you are saying, are you, perhaps, confusing the LSB with the checksum?

            Have a look at the manual,

            Byte 1 is the command, in this case 01 - Write Object
            Byte 2 is the Object ID, in this case 0B - A Gauge
            Byte 3 is the Object Index, here 1 or 2
            Byte 4 is the MSB, here always 0
            Byte 5 is the LSB, here 14 or 0A (i.e. decimal 20 or 10)
            Byte 6 is the checksum, which varies according with the other data.


            • neelespn
              neelespn commented
              Editing a comment
              I see, its a normal gauge, sorry,
              I was confusing the checksum with the LSB.
              but is it required to send a checksum,

            • neelespn
              neelespn commented
              Editing a comment
              here in the manual,

              The checksum is a means for the host to verify if the message received is correct. This byte is calculated by XOR’ing all bytes in the message from (and including) the CMD or command byte to the last parameter byte. Then, the result is appended to the end to yield the checksum byte. If the message is correct, XOR’ing all the bytes (including the checksum byte) will give a result of zero.

              so its required to send a checksum,
              the onluy thinng I need to find out now is how to ad XOR

          • #7
            checksum = W ;

            checksum ^= gauge ;

            checksum ^= c ;

            checksum ^= zero;

            checksum ^= 30;

            byte wTemp[] = { W, gauge, c, zero, 30, checksum};
            Serial.write(wTemp, sizeof (wTemp)), HEX;

            for calculation the checksum, I see no error comming from the display now, so thankz for your assistance.

            I'm confused, because when I'm using XOR, it give my the same problem that caused me to do the manually instead of the library.

            the problem is with the above code or with the library, it wont loop.


            • #8
              I can't say I'm familiar with the C that you are using, but I don't understand why you would use 'HEX', surely this would cause the data to be sent as characters converted from Binary to HEX?

              Connect RX from your programming device to TX from your controller and use Terminal to monitor what you are actually sending, I think you will find the format is wrong.