Davinci Jr Repetier Port (Page 7 of 9)

serial terminal assume everything you read is ASCII (0-256), you don't really see numbers from (0-64) because they are not assigned to characters. You are missing a lot of information by read it as ASCII. Check the software you are using and see if there are options to display it in number instead of text or ASCII.

Logging is also a great feature that PuTTY provides. It lets you output your entire session to a log file. To enable logging, follow these steps before you open your connection:
1. Select Logging from the category list on the left.
2. Choose your desired logging method (All session output, printable output, etc…)
3. Enter a file name.
4. Select the file handling settings.
5. Open your connection.

After finish, open your logging file with winhex. you can also open it with notepad++ and select everything then click plugin menu, converter, ASCII-> Hex

Yeah I was already logging to a file when I was checking this output before. I think it'll be better to get raw output captured in hex tho, so I'll do that

OK cool thing about this terminal app, is has a nifty little status indicator at the bottom that notes whether the Rx is good or if there's a frame error. This allowed me to quickly switch through baud rates and determine that the communication method that poroduces no frame errors is 115200 8N1.

Currently going to start a fresh log with this data.

AA 55—532 times
22 DD—571 times
11 EE--798 times
0C F3—387 times
F9 03—140 times
03 AB—354 times
0A F5—178 times
64 64—416 times
03 FF—159 times
03 FE--90 times

See attachment for color coded log files. My feeling is start with device id, followed by a value. mostly are paired, but my mach of pair may be affected if 00 is device ID.

my feeling is 03 is a device id,
F9 03—140 times
03 FF—159 times
03 AB—354 times
03 FE--90 times
is consequence of pair shift.

fingers crossed someone on here can make more sense of it than me

I have been watching the printer and it looks like commands are wrapped with a set of bits. There's a pause between requests, and each packet seems to begin and end with 11 EE, so you'll see this when it pauses: ## ## ## 00 11 EE 11 EE ## ## ##

Okidokie, now that I'm home I can switch around the pins. I'll go get captures from the U17 now

near the bottom I shorted Comparator 2's inputs prompting the system to think there was a jump in temperature. The fans immediately turned on, then went back off.

Here's something really interesting. U17 only seems to report temperature when there's a change. I disconnected the NTC and was getting completely consistent set of bits:

00 FF 00 FF 91 EE 00 FF 00 FF 11 EE < repeat repeat.

Attached is what happens when I hold the comparator inputs shorted, then release a few seconds later. The same consistent patter happens while I'm holding, and only changes on release.

U17 speak Martians, U2 speaks Venusian.

I don't have a DaVinci jr, but I do like patterns, so maybe this can be of some help.  Here's an excerpt from your temperature logs.  What's interesting is that there are clear message patterns, but they are being interleaved such that messages can be interrupted by other messages on the wire.  The bytes below are in the order of capture, but notice the lines with leading spaces are part of an earlier message.

11 EE 00 FF 00 FF 
11 EE 00 FF 00 FF 
91 EE 00 FF 00 FF 
22 DD 02 FD 10 00 10 EF 
22 DD 02 FD 10 00 10 EF 
22 DD 02 FD 20 00 20 DF 
22 DD 02 FD 20 10 30 CF 
22 DD 02 FD 20 20 40 BF 
11 EE 00 
22 DD 02 FD 20 30 50 AF 
         FF 00 FF 
91 EE 00 FF 00 FF 
91 EE 00 FF 00 FF 
91 EE 00 FF 00 FF 
22 DD 02 FD 10 00 10 EF 
22 DD 02 FD 10 00 10 EF 
22 DD 02 FD 20 00 20 DF 
22 DD 02 FD 20 10 30 CF 
22 DD 02 FD 20 
22 DD 02 FD 20 30 50 AF 
               20 40 BF 
11 EE 00 FF 00 FF 
91 EE 00 FF 00 FF 
11 EE 00 FF 00 FF 
22 DD 02 FD 10 00 10 EF 
22 DD 02 FD 10 00 10 EF 
11 EE 00 FF 00 FF 
22 DD 02 FD 20 00 20 DF 
22 DD 02 FD 
22 DD 02 FD 20 20 40 BF 
22 DD 02 FD 20 30 50 AF 
            20 10 30 CF 
11 EE 00 FF 00 FF 
91 EE 00 FF 00 FF 
33 CC 02 FD 20 01 21 DE 
11 EE 00 FF 00 FF 
22 DD 02 FD 10 00 10 EF 
22 DD 02 FD 10 00 10 EF 
22 DD 02 FD 20 00 20 DF 
22 DD 02 FD 20 
22 DD 02 FD 20 20 40 BF 
22 DD 02 FD 20 30 50 AF 
               10 30 CF 
11 EE 00 FF 00 FF 
91 EE 00 FF 00 FF 
91 EE 00 FF 00 FF 

There are also a large number of byte pairs that are binary inversions, that is the two bytes added together equal FF (perhaps a way to validate message structure or detect bit errors?).  I initially thought these could be hamming coded for error correction, but ham codes wouldn't result in perfect inversions.  For example:

11EE, 22DD, 33CC, 02FD, 10EF, 20DF, 21DE, 30CF, 40BF, 50AF

are all binary inversions.  In the temperature logs, the ones that aren't binary inverted seem to be followed by some form of check that is.

1000 10EF (10 + 00 = 10) and inverted (= EF)
2001 21DE (20 + 01 = 21) and inverted (= DE)
   ...
2030 50AF (20 + 30 = 50) and inverted (= AF)

The 91EE doesn't follow the pattern, however, it is 11EE with the high order bit turned on (bit error?).  Look kind of like saw wave pulses along with a heartbeat to me.

I don't think that 11 EE necessary precedes any message, in the temperature logs you can see that 22 DD come through without being preceded by a 11 EE and in the startup log you can clearly see 11 EE injected in the middle of messages:

0C F3 FA 03 FF 03 AB 00 00 00* 
33 CC 02 FD 10 64 74 8B 
                             *64 64*
11 EE 
0C F3 FA 03 FF 03 AB 00 00 00 64 64 01 00 03 00 
11 EE 
                                   *01 00 03 00 
11 EE
...
11 EE 
0C F3 F9 03 FF 03 AB 00 00* 
11 EE 
                          *00 64 64 01 00 03 00  

11 EE feels more like a heartbeat of sorts and messages just start with a valid byte inverted pair, indicating the type of message.  Also, I have a feeling there may be bit errors in the stream as the field of zeros in the startup log have single bit numbers in them and I have seen occasional messages that fail the byte inversion by a single bit.

00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 
00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 
00 00 00 00 00 00 10 00 00 00 00 00 00 00 00 00 

33 CC 02 FD 20 01 21 DE
11 EE 00 FF 00 FF 
32 DD 02 FD 10 00 10 EF    *** should be 22 DD
22 DD 02 FD 10 00 10 EF 
22 DD 02 FD 20 00 20 DF