suspected bug on ReadCV #4
Comments
|
Hi Laurent Strange. Let's try to find what causes the problem. Let's first explain my setup:
This is when I read CV1: What I remember (but it is a while ago when I wrote this code, so I don't recollect the details) is that after a write, eight individual Bit Verify Commands are send by the Command Station. That is indeed what we see with your output as well as mine. So that is OK. If I look at the data, the values of bit positions 0 and 1 differ, while the values for the other bit positions are the same. Since a value 3 means that bits 0 and 1 have a value 1, this seems correct as well. Don't get confused that for the bit manipulation / very commands you get back values between 224 and 231. See the explanation in Line 208 of the file sup_cv.cpp. In fact your results and mine seem identical, till line 3 from the bottom. You get a CV value back of 255, while mine says the value is 3. This difference is what puzzles me. The key seems to be the third line from the bottom. In your test you get back a CV Value of 255 (which is incorrect), but in my test I get back a value of 3 (which is correct). However, all the previous bit verify commands returned the correct value. Thus also your decoder should gave the right value for CV1 (=3). I guess we have to both study a bit better how SM programming exactly works. :-( Bye Aiko |
|
I tried the two other Command Stations that I have to get a better understanding how these differ in operation. This first check was with the Roco Multimaus in combination with 10764. Although this combination is able to write successfully CV values, it can not (according to the documentation) read/verify CV values. So that test didn't help. The next test was the OpenDCC Command Station (that I have, but hardly use). Although that Command Station is able to read / verify CV values, the behaviour is completely different compared to Lenz. OpenDCC starts with checking CV8 (Vendor ID) and CV29 (Config). I don't no why, but that could probably have a good reason. So the first thing I had to do was to extend the Array with test CVs (from 10 CVs to 29 or more), since otherwise it wouldn't show any CV values. After that I tried to read the value of CV1, but OpenDCC uses a slightly different setting than Lenz: where Lenz set the D-Value to 0, OpenDCC sets it to 1. OK, shouldn't be a problem. However, for ALL the 8 bits being tested, OpenDCC says that the bits are unequal. That is, like with your command systems, an incorrect conclusion. The weird thing is that your Command Stations, like the OpenDCC station, never see that two bits are equal. That may also lead to a different conclusion: these command stations do not recognise the ACK signal. Maybe therefore it is a timing issue of the ACK signal. Something Lenz doesn't seem to care, but the others do. Aiko |
|
Just to be complete: this is the trace while using the OpenDCC Command System. |
|
Dear Aiko After checking connexion to avoid any troubel i made some new tests. UNO +serial CV code ( dcc_pin =2 ack_pin =3) no other change. 1st test with: Ack is driving a MOSFET N channel with in drain side a 200r resistor CV to permit from Vin ( after a diode bridge from DCC to have the requeted 60ma load.) Dcc in work like a charme :) : every instruction is execute as soon as F0 Fx function number is change on desired decoder adress ( fast diode schottky + resistor divider (10K+10K) +mosfet n channel) Pull up on drain with 5V and go to dcc_in pin.) ( it s like the usual the famous 6N137 opto coupler) uint32_t FN_STATE =0; LOCO address is defined by CV29 = 32 : long function decoder with long adress so CV17 = 192 + CV18= 200 ( for test) test read adress from DR5000 get this result: F0 is a global ON OFF switch After that we drive outputs with: |
|
2de test conditions: here is the log: ` ` So same behavior. Next test |
|
3rd conditions tests: Here is the log and shoul be ok :) ` Now test CV17 as arbitrary choice: ` ` Next test |
|
4st test condition: Try to read CV29: ` Error reading on soft. Unable to read it New test with CV1: Before getting teh error message this is the log 👍 ` Next elt: |
|
I have change the ack to make blink all leds too so Read/Ack is ok (blink is oberved on all channel with Lockprogrammer read try) no way still having issue on read |
|
Last test done with LENZ LH100 v3.6 + LVZ100 v3.6 Same decoder and result get: ` ` |
|
Hi Laurent. I think I have found the error. After correcting the error it now works with my OpenDCC Command Station as well. I have updated in the Github repository the file "sup_cv.cpp", as well as the test file "CV_Access-Serial_monitor". Bye Aiko |
|
Dear Aiko Thanks for your support and reactivity! I made the required tests following your proposal with: Test 2.1: sup_cv.cpp updated on lib before compile step and loaded to UNO with New Serial CV ino load into decoder WRITE IS OK: updating CV18 from val 150 up to 151 17:26:50.797 -> Reset Command READ IS OK: check to verify results 17:27:52.302 -> Reset Command Other test with read CV1: ( val is 3) 17:32:22.574 -> Reset Command So looks like OK :) for mathcing with "ESU world" :) Well done! now i swap to LENZ to check potential side effect? |
|
Sounds good! :-) Thanks for your error report; such reports help to improve the software! |
|
Test 2.2: Same condition test but now DCC COMMAND STATION are LENZ LVH100 +LVZ100 Read adress after change: Look good. BUT its stange to receive CV19 elements dont you think? So i m a bit confused on how to get the final value and manage it to eupdate eeprom as exemple + reste decoder reading new CV values... May you can give me some tips for that.( good exemple in the lib should help) I will make some other tests with differents elements |
|
HI Aiko :) I finaly succeed in my tests to read and write without issue on some command station side. About LENZ LH100 side: With ESU LOCKPROGRAMMER it s the same kind of things. Unable to read/ write. I m suspecting power issue (to late to start on) I will test to with another diode bridge front + dcc in stage for the "Serial CV "snifer" and check results in parallel to compare. Thanks anyway for your updates. |
|
Hi Laurent For possible example code that deals with CVs and EEPROMs, you can look at AP_DCC_Decoder_Core. In principle, the decoder must be reset to ensure the new value is used before you do anything else. In practice (also with my programmer software for MACs OS) I sometimes set multiple CVs first, and do the reset after I've changed all necessary CVs. I'm a bit surprised to see the "1" offset with the DR5000. One possible way to deal with that, is to add DR5000 to the possible Command Stations that I "have" in CV19 (CmdStation) of my AP_DCC_Decoder_Core library. Talking about CV19, I have no clue why your Lenz system is quering that. In principle CV19 can be used for "Address Mirroring". I've "stolen" that CV for my decoders to deal with different behaviour of Command Stations. Regarding the tests on your Lenz LZV100 system, I don't understand why it behaves differently (calls CV29 as well as 19) compared to my test (only CV1). In my test I typed "8" (PROG), "Enter", "-" until the display shows CV, "Enter", "1", "Enter", "Enter". Did you do the same?? Error 2 on the LH100 says no feedback from decoder while programming. Bye |
|
Hi Aiko Sorry about my unclear items. HARDWARE ADJUSTEMENTS: Suggested optimised connections /connections: For the moment i did not use CV Serial monitor on UNO. (unconnected) ABOUT TESTS: Anyway if i used Address read i get error 2 or m 000 ( due to CV swap+1) ( PROG /DIR /ADR /A enter) LOCKPROGRAMMER: same behavior (SWAP CV+1) but need to change ACK layout to let have more delta load detected. Hope it will help to fix the +1 swap :) Laurent |
|
Hi Laurent Thanks, I think I understand.
A) Direct Configuration (=long form) B) Physical Register (=short form) C) Address Only: D) Paged Addressing Questions:
Depending on your answers, I might have some other questions. But let's do things one by one. Bye Aiko |
|
Hi Aiko I m focused on FUNCTION DECODER properly ( mobil decoder for coach or loco) . This is my target devlopment for witch one i suggest to share my basic exemples to your lib as exemples if you agree with that proposal? When i used LH 100 it s a" basic address mode" ( direct CV access) as you have discribed previously . CV by CV mode is OK with DR5000 CV read/write and Lockprogrammer read write CV only. ( just have +1) Anyway this system like the LH100 offer a ADDRESS read option that can deal with CV29 bit5 CV1 or CV17 CV18 to give you back/set the value. With your LH100 you should try this by: ADDRESS ACCESS: PROG/PROG/DIR/ADR A enter a value to set it or press enter direclty to get address. It should set address on desired requested CV if I not wrong. ( I never use it to set them I more confortable using ESU soft for my decoders or DECODER PRO) I have forget that your lib offered CV direct mode only so why i should have such results on my tests! ( making feedback address) I have another projet for a signal decoder as accessory decoder for wicth one direct mode should be enough. ( less CV to set than a mobile) Anyway it s sure that for a function decoder ( mobile) CV by CV is a bit too limited mode but shul be consider as a minimum INDEX address mode should be a good way to support with latest decoder and programmers. Now i need to identify the cv value received, manage it to update in eeprom and make the reset to load change on my code! Laurent |
|
Hi Aiko Hope you dont burn brain tto much like i did! I finaly fixed the+1 swap with appropriate recoding cv_operation function as follow. So now all test done on LH100 match perfectly: ` ` Please not i made a sanity check before update in the CV value class like it according NMRA value + some personnal uses on CV112 to CV119: ` ` I need again to perform some tests on it. This is the next step to fix! Regards |
|
Hi, I did not succeed in fixing reset value process by updating CV8 with a desired value to process a relaod of default value + reboot cpu ( in my exemple set value to 8 on CV8 should make a reset of val) This made an unknown behavior that required a push hard reset buton. I made some other tests on others CV in read only without issue, Changing any writable CV is ok too and take in charge. Anyway absolutly no idea why is not possible with CV8 reset process to default values. Any idea? Laurent |
|
Hi Aiko I missed all my test to reset by CV8 change. So I have decided to use a more powerfull solution in that case only to perform a "full soft reset" using watchdog option Tested with sucess applying it to main loop, read cv =>OK, write CV =>oK, apply reset CV (write 8 on CV8 = > OK Issue fixed. Anyway I suspected taht a full relaod of CV require may be a register reset or somthing similar, so that s the reason why "a jump to 0" reset option may not be enough or brik the process. I set watchdog to 1sec that look like a good timing for that timer. Regards |
|
Dear Aiko About the multimaus I advised you to put a look on that document from Roco. Anyway support of XPRESSNET V4.0 is a good improvment although only F29-F31 have been added for the moment ( not up to 68. May be for future updates?) CV read write process was updated too but require compatible command station. Laurent |
Dear Aiko
I used the CV_access_monitor and find some strange behavior on READ CV.
Hardware used:
NANO EVERY + Dcc In and Ack items.
Test conditions: DR5000 or ESU Lockprogrammer ( same kind of result)
When I want to read 1 CV (any of them) the output is a bit strange:
Thjis is the result get by your skech:
`
`
look like filter is missing?
And finaly unable to get the values
For write process it look like ok but unable to verify with read!
WRITE CAPTURE:
So i can t update or read correcly my cv! :( no luck!
A CV list print in main sketch gave me a list or eerpom values loaded at startup.
Any idea on such behavior or fix clue?
Regards
Laurent
The text was updated successfully, but these errors were encountered: