Go Down

Topic: Meccano MAX and Arduino (Read 5230 times) previous topic - next topic

bmd1103

Good work! - I haven't done anything with the Mega apart from using it to snoop on the Max communications.

Here is the list of checksums derived from the standard face displays provided under the "Programming" option.  I'll be away from home for a few weeks from Saturday so will have to work on the system on paper only.  If I can't come up with a reasonably easy formula, I might try a brute strength approach - generate messages for simple patterns such as a single LED, and try all 256 possibilities until I find one that works.

mrdreambot

Here is the UML class diagram of  the framework I am working on now. Still in progress. As I said earlier, I am using the GOF Chain of Responsibility Design Pattern.

mrdreambot

Need some time to digest your findings. I am going to be away for a week too. Enjoy your break.

mrdreambot

BTW, the max distance sensor is not an ultrasonic but an infrared device and haveing similar behavior as a Sharp infrared sensor.

bmd1103

OK - I've got an algorithm for the checksum for the LED array.

First, the 8 bits for each of the 16 columns have to be converted into numerical form.  The LS bit of each byte is the top one, rather than the bottom one as I assumed earlier, and each byte is therefore transmitted MSB first.

Second, the 16 bytes for the full display are added together using 1's complement arithmetic if there is an overflow, it is wrapped around and added in to the LSB position. The checksum flag value of 0xAF is also added in this fashion,

Third, the resultant is subtracted from 0xFF to get the checksum to be transmitted as byte 18 of the message.

Code: [Select]
byte checkSum(byte data[])
{
  int cs = 0;
  for (int i = 0; i < 17; i++)
  {
    cs = cs + data[i];
    if (cs > 255) cs = cs - 255;
    Serial.print(i);Serial.print("  ");Serial.println(cs);
  }
  cs = 0xFF - cs;
  return (byte)cs;
}

mrdreambot

bmd1103,

Question: after identifying the device ID=6 which is the face after the exchange:

Starting Max Tests...
FE FE FE FE 0 - 0
FE FE FE FE 1 - 0
FE FE FE FE 2 - 0
FE FE FE FE 3 - 0
FE FE FE FE 0 - FE
FC FE FE FE 1 - 0
FC FE FE FE 2 - 0
FC FE FE FE 3 - 0
FC FE FE FE 0 - 6

Do I need to send a command before sending the data for display? If so, what command code is it?

If not, does it mean one can send data to the Face at anytime? That appears to violate the protocol above?

I tried sending the data right after identifying the device. But it does not work. I also try send a command (cycle between 0 and f8 before sending the data, it does not work either.

I did not calculate the checksum but used your recorded AF, checksum in your Lead_array_message PDF for the various images.

Any suggestion will be appreciated.

bmd1103

mrdreambot,

The sequence I logged repeated the commands FF FC FE FE FE FE 8n twice - I don't know if that is the requirement. Then there is FF 00 FF 00 FF 00  - ~~, with no response from the  module, then it appears to start on the pwm sequence. 

However, I haven't looked for any more detail at the transition between the two modes and can't do any hands-on testing till I get home in a month.  I'll try and run my transition timing program on the startup sequence, or trigger my oscilloscope from the Arduino so I can grab the last couple of frames of the serial and the start of the pwm mode.
There is about a 33 ms delay between the pwm frames so you could try that between the serial and pwm as well.

So I'd suggest -
send

FF FE FE FE FE A1  - ~~
FF FE FE FE FE A1  - ~~
FF FE FE FE FE A2  - ~~
FF FE FE FE FE A3  - ~~
FF FE FE FE FE A0  - fe      Module 0 replies with 0xfe
FF FE FE FE FE A1  - ~~
FF FE FE FE FE A2  - ~~
FF FE FE FE FE A3  - ~~
FF FE FE FE FE A0  - fe      Module 0  repeats reply
FF FC FE FE FE 81  - ~~
FF FC FE FE FE 82  - ~~
FF FC FE FE FE 83  - ~~
FF FC FE FE FE 80  - 06      Module 0 replies with type code 6
FF FC FE FE FE 81  - ~~
FF FC FE FE FE 82  - ~~
FF FC FE FE FE 83  - ~~
FF FC FE FE FE 80  - 06      Module 0  repeats reply
FF FC FE FE FE 81  - ~~
FF FC FE FE FE 82  - ~~
FF FC FE FE FE 83  - ~~
FF 00 FF 00 FF 00  - ~~              ?? Change to pwm command ??

then wait 30 ms, then start sending the pwm strings.

Hope that helps.

mrdreambot

Tried different variations and delays but still not able to get any LED on the Face to light up. Shall try some more tomorrow and keep you informed.

bmd1103

#23
Aug 06, 2018, 10:00 am Last Edit: Aug 06, 2018, 10:01 am by bmd1103
mrdreambot-

If you are using the program I wrote to write to the array, the csFlag array is wrong - it needs to be

Code: [Select]
boolean csFlag[] = { true, true, true, true, false, true, false, true };

The original was written when I was assuming that the message was sent lsb-first.

I'm going to go back to my original data stream tests and try to translate them into the correct format - but it's easy to make a mistake.  I've written an Excel app to see if I can tidy it up but need to double-check the results against the hardware. (unfortunately, I can't attach an Excel file).

For the default horizontal bar, the correct sequence is:
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xE3
0xF5        - checksum marker
0x9E        - checksum

bmd1103

mrdreambot -

I've modified the list of face array data - see the attachment.  I haven't completed it but have gone through my face array designer and verified the hex bytes and checksums.  Try these and see if they work.

mrdreambot

BMD1103,

Thanks for spending time on your trip to do this. I am using my own code. Using your new data, it is still not working for me. I have the following:

FF FF F1 E6 E4 B1 7F 7F 7F 7F F1 E6 E4 F1 FF FF F5 2D
Checksum: 2D vs EC
F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 E3 F5 9E
Checksum: 9E vs 9E
Starting Max Tests...
FE FE FE FE 0 - 0
FE FE FE FE 1 - 0
FE FE FE FE 2 - 0
FE FE FE FE 3 - 0
FE FE FE FE 0 - FE
FC FE FE FE 1 - 0
FC FE FE FE 2 - 0
FC FE FE FE 3 - 0
FC FE FE FE 0 - 6
Last device has been discovered...
Face: Connected at position: 0
Device #0: Face
0 FF 0 FF 1 - 0
0 FF 0 FF 2 - 0
0 FF 0 FF 3 - 0
0 FF 0 FF 0 - 0
Face: Connected at position: 0
Device #0: Face
0 FF 0 FF 1 - 0
0 FF 0 FF 2 - 0
0 FF 0 FF 3 - 0
0 FF 0 FF 0 - 0

This first array is the happy face in your latest pdf. Note that the checksum is different from using the algorithm you posted. The second array is the horizontal line. The checksums agree.

The exchange is similar to your working observation. After sending 0 FF 0 FF x - y 2 times, I waited for 30 ms before sending the array MSB first. I tried sending them MSB first and LSB first and no LED was lit. Just to confirm, there is a start bit consisting of -132 +564 -140 ie, 132 us low, 564 us high and 140us low, which is followed by the values of the array. And there is no stop bit. Is this correct?

BTW, don't ruin your holidays working on this. It can wait. I can work on other aspects of the project.

bmd1103

No problem- it's too hot here (in the UK) to do a lot ( - and my room is on the shady side of the house).

I'm working with a timing base of 140 us. The "preamble" is 1 time interval LOW, 4 HIGH, and 1 LOW.  Then each message bit is made up from 1 HIGH, 1 HIGH or LOW depending on the data bit, and 1 LOW.  There is something at the end of the message but I have not been able to resolve it - it looks as if there is possibly some tri-stating going on as there is a definite exponential charge curve from LOW to HIGH,  followed by a LOW. It looks as if I'll have to check that out when I get home.

mrdreambot

#27
Aug 07, 2018, 01:00 pm Last Edit: Aug 07, 2018, 01:20 pm by mrdreambot
Success at last! All that is missing is a stop bit. After the start sequence followed by the data, you still have to send a stop bit consisting 550 us high and then low.

You have to precede the sending of the image data by the data stream (00 ff 00 ff) every time you want to update the Face:

Face: Connected at position: 0
Device #0: Face
0 FF 0 FF 1 - 0
0 FF 0 FF 2 - 0
0 FF 0 FF 3 - 0
0 FF 0 FF 0 - 0
Displaying happy face...

Here are photos displaying a happy face and a sad face.
 
BTW, the check sums of the faces in your latest pdf are not correct. Have to replace them with the check sums calculated using your algorithm posted.

Thanks for your help! Enjoy your stay in the UK ;-)

bmd1103

Great! - so the start sequence (140 us LOW, 560 us HIGH, 140 us LOW ) needs to be repeated at the end.

I've attached my Excel spreadsheet for you to try out and check - should make it easier to come up with other face patterns.  It includes the checksum calc. as per my algorithm.  Hopefully, its operation is explained adequately.  I might play with it a bit more to make it less likely to be tampered with.  The password is Max.

I want to use the display to show dynamic patterns, and that's going to be quite hard on processor resources, so I;m thinking of getting hold of a Nano and using it as a dedicated processor - pass the Nano a pattern and it takes care of the updates etc.

Anyway, thanks for your help and I hope to have a few things to show you once I get back to base.

mrdreambot

No need for the initial LOW as the previous bit will always end with a LOW. After sending the 18-byte pattern, just send a 550 us HIGH following by LOW and don't have to time the LOW, just set it to LOW

Let's have a quick calculation (4 x (6 + 1) + 18) bytes x 10 bits/byte x 430 us/bit = 197,800 us or roughly 200 ms to update the face pattern. This means that you can update the face at a maximum of 5 times/sec. Limitation is the protocol and not the speed of your microprocessor.  Owing to the weird protocol, certain exchanges using HIGH/LOW to represent 1/0 and others using duration of the HIGH pulse to indicate 1/0, you can't use a comm port. I have to use bit-banging tying up all microprocessor resources. This means, yes, if you have to update the Face at more than twice a sec, you'll have to use a dedicated processor or don't have any resources left for other control functions.

I shall experiment with your images and do a scrolling text message on the Face and see how it goes during the weekend.

Go Up