Shop OBEX P1 Docs P2 Docs Learn Events
Reading DCC data using a propeller on track. (digital model railway control) - Page 2 — Parallax Forums

Reading DCC data using a propeller on track. (digital model railway control)

2»

Comments

  • Clock LoopClock Loop Posts: 2,069
    edited 2018-01-12 12:11
    I actually like what I see when I look at the prop scope its self as far as its probe circuitry and adc....

    I found some info about open scope ...

    They have some info...

    https://github.com/rosco-pc/OpenScope




    Hmm...
  • Clock LoopClock Loop Posts: 2,069
    edited 2018-01-16 16:04
    Using some of the propscope hardware (a2d) still requires me to code some software side.... But I am almost done with the schematic and making the pcb foot prints plus schematic parts.. Since I had to redo most of the propscope schematic, I did it all, plus the pcb.

    Now I get to hack it up to fit my need.

    So... to start I simply modified the parallax visual basic demo program for the propeller...
    To run on the propscope. (so nothing is happening in the code but the AN018 code minus its I/O operations, it just communicates with the pc at 2Mbaud.

    I had to find a full duplex serial plus object and Jonathan Dummer(lonesock) made one that has killer speeds using two cogs. NICE! THANKS!
    "Fast Full-Duplex Serial"
    http://forums.parallax.com/discussion/comment/1212013/#Comment_1212013

    Heres v1 of FFDS1
    http://forums.parallax.com/discussion/143514/fast-full-duplex-serial-1-cog-a-k-a-ffds1



    But the data that the VB program is receiving/sending is super slow, the code is too slow, so i will need to work on that, (serial port needs to be made into a stream object or something, not sure, gotta read more)

    http://www.parallax.com/downloads/an018-communication-pc-application

    So some code changes are needed. Along with how the serial port is used, its very slow as you can see by the video.
    The data on the propside and over the serial, is going much faster than 10hz, but this simplistic vb code only allows that. (the serial function is triggered only every 20ms due to vb timer limits. I don't know enough yet about vb to make it show the 2mbit data displaying rate.

  • Clock LoopClock Loop Posts: 2,069
    edited 2018-01-17 01:14
    So you think you're getting past a problem, and a new one shows.... hmm perhaps 2Mbit of data dumping into the vb buffer of 1024... might not be so good.. and when i turn the port off... no over flow... hmmm

    One would hope the modern visual studio would have better debugging ability.. but it just says that debugging isn't possible.
    So some debugging info does show in that popup, but not much, you havta kinda know what your program is doing to guess what its doing wrong.
    2018 and ms debugger still just as useless. Its also possible im doing something wrong, or the free version of studio dosen't allow it.

    Hmm., actually this looks like im overloading my send buffer...
    stackoverflow.jpg


    This post is still yet another post spam as a result of not being able to add attachments to previous posts.
    802 x 148 - 27K
  • kwinnkwinn Posts: 8,697
    Debugging is a bear no matter the tools you have. Single stepping and logic analyzers work but are incredibly slow. Software debuggers are not much better unless you have some idea of where the problem is. Debug statements or breakpoints in modules and subroutines help but are tedious to add.

    One of the neatest ideas back in the day was adc's on the address bus and an oscilloscope in xy mode to see where the program was executing. Later the ADC's and scope were replaced by decoders and leds. Of course that required an external address bus that could be accessed so it is not much use on today's microcontrollers.
  • Clock LoopClock Loop Posts: 2,069
    edited 2018-01-17 23:16
    kwinn wrote: »
    One of the neatest ideas back in the day was adc's on the address bus and an oscilloscope in xy mode to see where the program was executing.

    Gonna havta try that one day...


    I found that the vb project that I based this project on has an old version of CLR put into a config file...
    programname.vbproj Has a line in it that looks like this...
    <TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
    

    If your file has a version that is older, then you need to replace your version, with v4.6.1 in your programs .vbproj file.
    Thats assuming you in fact do use the latest visual studio with the latest .net dev framework installed.

    This allows debugging while running the program live(you can change the code) if you are on a 64-bit cpu.
    (you must turn off native code debugging in the debugger engines) located in your project properties page.)


    This is funny, so i did all this to make my clr version able to debug and change code live, but it then says changes are not allowed while running lol. BUT at least my cpu and memory profiler both work now... From what I read, the live code debugger/change dosen't work anyway.
    But its nice that my code is now using a later clr version. That is an important thing if your code can handle the new version, it makes sense why the clr didn't automatically change with the new version installed, but when I loaded the old project in vb, studio should have asked me if I want to use the latest version of clr with my project.

    Meh.
  • Clock LoopClock Loop Posts: 2,069
    edited 2018-01-17 21:59
    I think this thread might need a warning image, its starting to get ....

    learncurve.jpg
    440 x 485 - 18K
  • Clock LoopClock Loop Posts: 2,069
    edited 2018-01-17 22:40
    Delegates? Did microsoft frame its vb code structure from a convention?
    Delegate.jpg


    Well, some progress.. much faster serial interfacing code... not sure if its at its max yet... (as far as spin)
    505hz ... the amount of serial cycles my program goes through in a second.
    (a serial cycle includes the entire serial data packet of
    myheader      Byte    "!P1", 10, 0
    
    Thats seriously fast for a human interface, but seriously slow for any kind of data stream.
    Its a good thing i don't know what im doing in vb, because those numbers are entirely too slow to be 2mbit if I understand how much data i am dealing with per serial cycle.


    speed.jpg
    552 x 327 - 43K
    776 x 319 - 83K
  • Clock LoopClock Loop Posts: 2,069
    edited 2018-01-18 07:15
    I guess I am in fact re-writing the propscope software,.. after all..

    So I purchased a few prop scopes to have more than 2 channel on screen...
    propscopeVB.jpg


    Yea, not gonna happen....

    From what I can tell, hanno is MIA. Before diggin into this vb and stuff, I tried to reach out to hanno for support on my developer copy of his viewport, but some of his websites are shut down, the forms on sites that do work, the contact page show no email, and doesn't even work... the latest site has the same form for support as the one on the viewport page(the viewport one dosen't work)....

    Seriously, multiple instances is literally a check box in vb, sure database might be an issue if its used with multiple instance,,,, but is it even used with propscope...

    Yawn.... Time to reinvent the same wheel that oh i dunno 40 other people did... but this time, its open source. no more redoing THIS wheel. Its just gonna take me a long time to do... I have noticed here in the forums, much support for the prop and the code... so ... i think i'll continue to tackle the vb pc side of the interface,,,
    I guess I should make the interface look like a scope to begin.. that part is easy.. the functional code.. not so...

    But after seeing that multiple instance error, I see the propscope was also written (ironically) in vb.
    So my task here is most likely possible, but talk about a mountain to climb.

    The prop scope software... Streaming is BUGGED, the Tools-->manage prope is BUGGED, the dial for the resolution is BUGGED, ZOOM and PAN...heh... dont even try those, etc...

    Do I want to do this? No, it makes it easier for the propscope to be copied, but this software has ran me into a brick wall for the last DAMN time.
    But don't think making abandon-ware is a very nice thing to do to products that are still on the market.


    The hardware alone tho is worth it, especially when they are on sale for 50% off. Nice probes, nice bnc connectors, the usb cable feels like it has nice conductors inside...

    In my opinion, the propscope is a hardware product for developers who wish to make hardware like it, or software to run it.....,it also has "free" software for demonstration of the hardware, free usually means no support.

    Also the propscope is a great platform for testing 6.25mhz programs, the pcb is a 4 layer pcb with ground planes, the analog and digital grounds are separated(for the most part).
    It has a metal body for better shielding...


    Anyway.. for those that hate vb.....
    Don't worry, i'll port it. :D
    And if I can't, I'll rewrite it in c once i do the more simple vb. (i found lots of opensource vb scopes that have tons of functions to be ripped)
    Me and whos army?



    "You want me to hack the planet? You're dreamin', pal! Oh, there are Hot Pockets involved? Time to get serious."


    I'll just end up with vb code that looks like this...
    1*RXbCXaeMjkt3wnl34NcgoQ.png

    And then finally realize what kind of learning curve I have encountered.

    1*m381A1XUItlhwHat_OIqoA.png
    476 x 434 - 50K
  • kwinnkwinn Posts: 8,697
    Sometimes it is easier (and better) to analyze the old software or interface to discover the basic functions it performs and then use a modern well supported language you are familiar with to reproduce those functions.
    In many cases I have discovered that the effort needed to understand software someone else wrote well enough to make changes to it has been much greater than it would have been to start from scratch.
  • kwinn wrote: »
    Sometimes it is easier (and better) to analyze the old software or interface to discover the basic functions it performs and then use a modern well supported language you are familiar with to reproduce those functions.
    In many cases I have discovered that the effort needed to understand software someone else wrote well enough to make changes to it has been much greater than it would have been to start from scratch.

    I even found out that the same applies to software I wrote myself 25+ years ago...

    Mike

  • I haven't looked at Hanno's Software in detail, but the Software loads the PropScope every time, it is supposed just to have Calibrations in ROM.

    So we are able to intercept the load and catch a binary. The important part will be in assembler and it should not be soo problematic to find cog-images.

    Has anyone a P1 disassembler? Never thought about that before.

    Enjoy!

    Mike
  • Clock LoopClock Loop Posts: 2,069
    edited 2018-01-18 22:22
    Umm, I would say, that you probably shouldn't disassemble the current software for the propscope or the binary.

    Clearly up to this point the writer of the software has failed to see the benefit that opensource gains you in the long run.
    And such, has chosen to not open it.

    SO technically, reverse engineering it and using the current binary could be illegal if I chose to base this project on any of it.

    I am not basing this software on anything related to the current propscope software, the fact that its VB is MERELY COINCIDENTAL (parallax offered AN018, which contains the vb code that this project is based on.)


    I see what you mean tho, the FUNCTIONS the hardware does is not dependent on the software, and documenting those functions using the free software is what you are talking about.

    I plan to do much more than the propscope software allows, since i am seeing so many o-scope vb opensource programs with all the code already done for all those functions.

    Time to adapt it all, and then write spin/pasm code to do it.


    I am, in fact, rewriting the pc software and the prop scope hardware (but like you say i will use OPENSOURCE code that I find on the net from other peoples vb oscopes.)

    Unless the writer of the current binary just opens it, its pointless to rev engineer it when that still limits you to using a locked packed binary.



    I want to, and am going to, make the propscope firmware a modifiable thing, with the possibility that a communication protocol could be used that aligns with labview protocols.

    I AM going to need LOTS of help making the firmware and software as my programming techniques knowledge isn't polished, right now im "opening a can of beans with a rock".

    I have looked into the subject of using the current firmware, ....

    I don't know what I would do if I couldn't read the prop code that I have written, and still figure out whats going on for the vb computer side of the link.

    Without seeing the Prop code(and inserting debugging), so you can identify issues with your own code, its virtually pointless to use locked firmware.
    From what I can tell, you knowing programming, know that its probably easier just to re-write the prop firmware.

    Plus then its all open and can be improved upon by the community. (and will probably be, since I am not fluent in algorithmics.)
  • Clock LoopClock Loop Posts: 2,069
    edited 2018-01-19 03:16
    Speed, yum. Hey, this is kinda fun. Thanks to all the people who put code on the net to let people learn.

    I don't mind causing arithmetic overflows... when im testing the loop speed possibilities of multi threads...
    I guess i can't turn the thread.sleep(0) off.
    (i didn't realize telling a thread to sleep for 0 would have any difference... i guess its the sleep function its self, preventing the overflow)

    I suppose no delay counting loops are the next step for better granularity... state machines with threading.

    Perhaps im missing it but i see no built in function in vb with a sleep of less than 1ms. Thats funny.

    sleepthread.jpg

    Time to get the send and receive loops in their own threads.. that should speed things up alot...

    Gotta love having 1.6ghz looping capability... mmmm threading...

    My variables are smoking...

    1.6ghzVariable.jpg
    442 x 141 - 16K
    761 x 301 - 82K
  • Clock LoopClock Loop Posts: 2,069
    edited 2018-01-21 01:40
    Bit0 = 750hz

    8 bits + 1 start and 1 stop = 10 bits per serial loop.

    1 serial loop for every set of the header(4 bytes) and the data (16 bytes)

    Byte 1 is where bit0 to bit7 is stored.

    VB counts when the bit transitions from 0 to 1.

    Byte 0 and byte 2 to 16 is un-used but still transfered data.
    maths..





    20 bytes * 10 bits per byte = 200 bits.

    200 bits * 1.5khz serial cycle rate =




    Total data rate:
    300,000 bits per second.

    The prop isn't sending data fast enough.

    Spin is my limit here..

    PRI PC_CommsTX | index1                                                    ' Declare private method and 2 local variables
    
    
      serial[0].start(RX_PIN, TX_PIN, PC_BAUD)                                   ' Start UART (FullDuplexSerial) cog
    
    
        Repeat        
    
        
            serial[0].str(@myheader)     'send header
          
            index1 := 0
    
    
            SendData := SendData + 1                    ' Rotate/fill second byte of array
            dataout[1] := SendData                                              
                
            
            Repeat index1 from 0 to 15                                                  ' Send 16-byte packet to PC
                serial[0].tx(dataout[index1])
    


    I noticed bit0 is 1/2 the total serial cycle rate, makes sense..

    750 transitions times 2 bit states times 200 bits is 300kbps.
    750 x 2 x 200 = 300000


  • Clock LoopClock Loop Posts: 2,069
    edited 2018-01-21 16:14
    To test the spin limits I decided to test at different baud rates only.
    I also set 2 stop bits for these screen shots to see if i could get more stable header.


    115.2K
    115k.jpg

    250K
    250k.jpg

    500K
    500k.jpg

    750K
    750k.jpg

    1M
    1mBit.jpg

    1.5M
    1.5mBit.jpg

    2.0M Spin tops out at 2Mbit, (the serial port no longer slows spin down, its the other way around)
    2.0mBit.jpg





    2.5M
    DOSEN'T WORK. (bad header sync) Odd...



    3.0M
    I AM able to get 3MBit connection with sync. I wouldn't have sync if the data wasn't really 3mbit.
    The serial loop rate isn't any faster at 3mbit because spin is doing the data send, and can't go faster.
    I will need to do my data cycle and serial send in pasm. Hmm, yet another language..

    3.0mBit.jpg



    Technically, i can code the vb to take any data rate and not even touch the propscope's code (until the vb interface is done), as long as i know how my data is organized ... this then just leaves the prop side to run the main propscope i/o (spin), package the a2d and chunk it out to the pc(pasm).

    Verdict: VB is plenty fast. VB interface can be done. Spin propscope interface can be done.
    No idea how to do: a2d pasm and serial data frame send/recieve pasm.

    :D
    766 x 415 - 198K
    766 x 415 - 196K
    766 x 415 - 195K
    766 x 415 - 196K
    766 x 415 - 196K
    766 x 415 - 193K
    766 x 415 - 197K
    766 x 415 - 199K
  • Clock LoopClock Loop Posts: 2,069
    edited 2018-03-24 03:54
    Its easier to develop my little rail tool now, than to redo the propscope software and firmware.


    For the latest developments, I have investigated more.

    I found that the sdxn136ps decoder model has a big issue with its transponding circuit or code, and its very bad.

    All the best features of this decoder, transponding, ops mode readback, etc... are useless.

    This is what is known as a true lemon, in the manufacturing world, since all 13 of my sdxn136ps decoders do this.


    It affects the programming track also and will report its id as random ids that are in the system.

    The transponder is normally only supposed to squak at the proper time, but the sdxn136ps decoders transponder will squack at random times, this causes devices like the bxp88 and the bld +rx4 to report incorrect locomotive id's in the zone that the sdxn136ps decoder is in.

    I have multiple sdxn136ps decoders that all do this, personally i think its a bug in the design of it.

    This is partly why i am trying to develop this tool, its hard to see what is going on, on the rail.

    If I can't get these sdxn136ps decoders fixed, I am going to reverse engineer them, desolder all the parts, and make my own transponding sound decoder with the propeller chip and a micro sd card.
    (i think i may just do that anyway, it would be awesome to have my own transponding sound decoder, and one that was open source for everyone too :D )

    Everyone already did the (deep code)sound work for the propeller, so i just need to bring it all together(multiple systems integration), and I am pretty good at that, i am not so good at pasm.
  • Clock LoopClock Loop Posts: 2,069
    edited 2018-03-24 03:47
    A screen shot of a sdxn136ps decoder stealing the id's of any in the slot list. VERY BAD. Its an identity thieving decoder.

    This shot shows the program jmri controlling my layout. The engine 3780 is located in zone8 and has a sdxn136ps decoder in it.
    You can see the reports show that all 3 locomotives in zone 8, that is because of the sdxn136ps bug.

    The locos in zone1 (333) and zone 4 (1412) are perfectly working dz123 non-sound decoders, they do transpond properly.
    They are not making reports that are false.

    sdxn136psBUG.jpg
    2559 x 1418 - 1M
  • @"Clock Loop" said:
    To test the spin limits I decided to test at different baud rates only.
    I also set 2 stop bits for these screen shots to see if i could get more stable header.

    Is this VB interface based on the "QuickStart Communicator" app I wrote back in 2010? Just curious...I don't see that app anywhere on here, but the interface looks familiar.

Sign In or Register to comment.