Menu
▾
▴
srcpd-devel
|
From: Simon A. <sim...@gm...> - 2021-02-23 16:03:47
|
Dear all, first of all I'd like to thank all the devs for their continuous effort of keeping srcpd available. I'm very glad to have found it a few months ago and have been running my setup with it since. Now I've stumbled upon an issue locking GLs that I hope you can help me with: Whenever I try to lock one GL, the server seems to lock all GL but without sending 100 INFO messages about it. Here is what's happening (locking from session ID 887): -> SET 1 LOCK GL 78 0 200 OK 100 INFO 1 LOCK GL 78 0 887 -> GET 1 LOCK GL 78 100 INFO 1 LOCK GL 78 0 887 As expected so far. But when I call GET on locks for other GLs I get: -> GET 1 LOCK GL 3 100 INFO 1 LOCK GL 3 0 887 for all of them without ever requesting a lock from any session. If I connect a second client at this point, the second client will receive INFOS about LOCKs on all GLs after the handshake: 100 INFO 1 POWER ON 101 INFO 1 GL 3 N 1 28 1 100 INFO 1 GL 3 2 0 28 0 100 INFO 1 LOCK GL 3 0 887 101 INFO 1 GL 78 M 2 14 2 100 INFO 1 GL 78 2 0 14 0 0 100 INFO 1 LOCK GL 78 0 887 101 INFO 1 GL 256 N 2 128 2 100 INFO 1 GL 256 1 54 128 1 0 100 INFO 1 LOCK GL 256 0 887 The server is running srcpd 2.1.3. Can you explain this behaviour? It seems to be working as I'd expect for GA devices, by the way (lock one, the others remain unlocked). Thanks for any advice! Best regards, Simon |
|
From: Guido S. <gui...@gm...> - 2021-02-23 18:39:36
|
Am 23.02.21 um 17:03 schrieb Simon Ahrens: > Dear all, Hi Simon, > Now I've stumbled upon an issue locking GLs that I hope you can help > me with: Whenever I try to lock one GL, the server seems to lock all > GL but without sending 100 INFO messages about it. Here is what's > happening (locking from session ID 887): [...] > > The server is running srcpd 2.1.3. Can you explain this behaviour? It > seems to be working as I'd expect for GA devices, by the way (lock > one, the others remain unlocked). > Locks are not heavily tested. I don't know if there is any SRCP client which supports this feature. Having just a quick glance at the source code I found regarding the GL devices locks are implemeted on bus level. I have no clue if this is intended or not, but I guess this is an error. Guido |
|
From: Simon A. <sim...@gm...> - 2021-02-23 19:36:48
|
I see, thanks for your answer. I noticed that timed locks for GL don't seem to work either - they always return 0 seconds. I'm currently writing a client application and easy multi client "cooperative" control is a priority for me. The lock features, in my opinion, are a really neat feature for that. Granted, GA locks probably a bit more so than GL locks. Still, I'll look into the srcpd source code and see if I might be able to fix that. At first glance the GL locks don't seem to do much different from the GA locks... can you give me a hint on what you mean by "GL device locks are implemented on bus level"? Looks like handle_setcheck(...) calls lockGA(...) for GA and cacheLockGL(...) for GL... and those functions - at first glance - look rather similar? Sorry - this is only the second time I've looked into the sources... Thanks again and best regards, Simon On Tue, Feb 23, 2021 at 7:39 PM Guido Scholz <gui...@gm...> wrote: > Am 23.02.21 um 17:03 schrieb Simon Ahrens: > > Dear all, > > Hi Simon, > > Now I've stumbled upon an issue locking GLs that I hope you can help me > with: Whenever I try to lock one GL, the server seems to lock all GL but > without sending 100 INFO messages about it. Here is what's happening > (locking from session ID 887): > > [...] > > The server is running srcpd 2.1.3. Can you explain this behaviour? It > seems to be working as I'd expect for GA devices, by the way (lock one, the > others remain unlocked). > > Locks are not heavily tested. I don't know if there is any SRCP client > which supports this feature. > > Having just a quick glance at the source code I found regarding the GL > devices locks are implemeted on bus level. I have no clue if this is > intended or not, but I guess this is an error. > > Guido > > > _______________________________________________ > Srcpd-devel mailing list > Src...@li... > https://lists.sourceforge.net/lists/listinfo/srcpd-devel > |
|
From: Simon A. <sim...@gm...> - 2021-02-23 19:44:33
|
Oh... sorry, I think I see what you mean about the bus level... it's missing all/most of the address specific references a la ".gastate[addr]". Alright... I'll dig deeper in the next weeks :) On Tue, Feb 23, 2021 at 7:39 PM Guido Scholz <gui...@gm...> wrote: > Am 23.02.21 um 17:03 schrieb Simon Ahrens: > > Dear all, > > Hi Simon, > > Now I've stumbled upon an issue locking GLs that I hope you can help me > with: Whenever I try to lock one GL, the server seems to lock all GL but > without sending 100 INFO messages about it. Here is what's happening > (locking from session ID 887): > > [...] > > The server is running srcpd 2.1.3. Can you explain this behaviour? It > seems to be working as I'd expect for GA devices, by the way (lock one, the > others remain unlocked). > > Locks are not heavily tested. I don't know if there is any SRCP client > which supports this feature. > > Having just a quick glance at the source code I found regarding the GL > devices locks are implemeted on bus level. I have no clue if this is > intended or not, but I guess this is an error. > > Guido > > > _______________________________________________ > Srcpd-devel mailing list > Src...@li... > https://lists.sourceforge.net/lists/listinfo/srcpd-devel > |
|
From: Simon A. <sim...@gm...> - 2021-02-24 16:04:56
|
Alright, looks like I got it working. GL locking is now glstate-based in my local copy and timed locking of GLs is working. Is anybody interested in the changes, as simple as they may be? Has anybody been working towards a 2.1.6? Best regards, Simon On Tue, Feb 23, 2021 at 8:44 PM Simon Ahrens <sim...@gm...> wrote: > Oh... sorry, I think I see what you mean about the bus level... it's > missing all/most of the address specific references a la ".gastate[addr]". > Alright... I'll dig deeper in the next weeks :) > > On Tue, Feb 23, 2021 at 7:39 PM Guido Scholz <gui...@gm...> wrote: > >> Am 23.02.21 um 17:03 schrieb Simon Ahrens: >> >> Dear all, >> >> Hi Simon, >> >> Now I've stumbled upon an issue locking GLs that I hope you can help me >> with: Whenever I try to lock one GL, the server seems to lock all GL but >> without sending 100 INFO messages about it. Here is what's happening >> (locking from session ID 887): >> >> [...] >> >> The server is running srcpd 2.1.3. Can you explain this behaviour? It >> seems to be working as I'd expect for GA devices, by the way (lock one, the >> others remain unlocked). >> >> Locks are not heavily tested. I don't know if there is any SRCP client >> which supports this feature. >> >> Having just a quick glance at the source code I found regarding the GL >> devices locks are implemeted on bus level. I have no clue if this is >> intended or not, but I guess this is an error. >> >> Guido >> >> >> _______________________________________________ >> Srcpd-devel mailing list >> Src...@li... >> https://lists.sourceforge.net/lists/listinfo/srcpd-devel >> > |
|
From: Bernd W. <f.j...@t-...> - 2021-03-22 10:28:03
|
I have submitted the following patches against Rel.2.1.5: Only No 13 is specific for Raspberry Pi. 11 i2c-23017 general accessories driver This driver controls GAs (accessories) by the I/O ports of MCP23017 16Bit-I/O-Expanders driven by the i2c-dev interface of the Linux kernel (similar to the i2c-dev driver, but other hardware). see README.i2c-23017 contained in the diff for more explanation. 12 bw-rs232speed_2.1.5 improved NMRA timing This patch implements an additional value for the DDL configuration setting <improve_nmradcc_timing> termios2 is an alternative method in linux to set a non-standard baudrate if the hardware supports it. In contrast to the existing divisor method it supports newer linux kernels as well. Depending of the base baudrate more granular baudrate settings may be possible. See man 5 srcpd.conf contained in the patch. 13 bw-raspidefs_2.1.5 Raspberry Pi control lines for DDL Raspberry Pi has UART interface(s), but no support for some RS232 control lines like DTR or RI. This patch allows to use Raspberry's GPIOs as RS232 control lines for DDL, if the booster needs so. see README.raspberrypi contained in the diff for more explanation. All diff files are based on the tagged version RELEASE_2_1_5. Merging diffs requires more and more manual intervention and may be error-prone. So for future Patches, a new base containing the patches submitted until now would be helpful. My ideas for future patches are: - ACK-detection for NMRA programming. Theoretically, supporting the RI line by Patch 13 should already provide the functionality, but practically, the self-made low cost wiring used by me needs more programming for timing and signal detection. - port the use of Raspberry Pi's SPI interface as DDL signal source from http://siggsoftware.ch/wordpress/srcpd-mit-mfx-und-anderen-erweiterungen/ As my Raspberry Pi 1 has only one UART, a second signal source is needed for the programming track. - perhaps porting the prioritizing of Loc stop commands from Sigg software As submitting changes for ddl.c means touching a heart peace of a stable/mature software, I'm trying to be careful to prevent undesirable side effects, but I can only test with my limited hardware. Please let me know if such kind of patches is desirable from your point of view. Regards Bernd |
|
From: Harald B. <hab...@kt...> - 2021-03-22 12:18:05
|
> - ACK-detection for NMRA programming. Theoretically, supporting the RI line by Patch 13 should already provide > the functionality, but practically, the self-made low cost wiring used by me needs more programming for timing > and signal detection. As I have had part of the code that does the ack detect in DCC++EX https://dcc-ex.com/ I can tell you that ack detection is a major PITA because many decoders do _not_ do what they should according to NMRA spec. Especially considering the so called 6ms pulse timing. We now allow ack pulses from 2ms to 12ms and have runtime tunable ack pulse level and duration. Some decoders need more startup time (reset packets) as well. Harald. |
|
From: Bernd W. <f.j...@t-...> - 2021-04-14 12:37:32
|
Dear Harald, Thank you for the warning about decoders and also for the analysis made at https://www.stacken.kth.se/~haba/slamra/dcc/ackpulse/. The TAMS decoders which I use provide ACK only for reading some CVs ond not for others. Verifying works better. (For fairness it should be mentioned that they don't offer ACK as a feedback method in their document, only RailCom.) The wiring which I use is based on your https://www.stacken.kth.se/~haba/slamra/dcc/ackdetect/ - Thank you for having shared that. Bernd Am 22.03.21 um 13:02 schrieb Harald Barth: >> - ACK-detection for NMRA programming. Theoretically, supporting the RI line by Patch 13 should already provide >> the functionality, but practically, the self-made low cost wiring used by me needs more programming for timing >> and signal detection. > > As I have had part of the code that does the ack detect in DCC++EX > https://dcc-ex.com/ I can tell you that ack detection is a major PITA > because many decoders do _not_ do what they should according to NMRA > spec. Especially considering the so called 6ms pulse timing. We now > allow ack pulses from 2ms to 12ms and have runtime tunable ack pulse > level and duration. Some decoders need more startup time (reset > packets) as well. > > Harald. > |
|
From: Bernd W. <f.j...@t-...> - 2021-02-24 17:20:45
|
Am 24.02.21 um 17:04 schrieb Simon Ahrens: > Has anybody been working towards a 2.1.6?> Dear all, I'm currently preparing the following Patches against Rel.2.1.5: i2c-23017 This driver controls GAs (accessories) by the I/O ports of MCP23017 16Bit-I/O-Expanders driven by the i2c-dev interface of the Linux kernel (similar to i2c-dev, but other hardware). rs232speed alternative method to improve NMRA DCC timing for the DDL driver - works for newer Linux kernels using termios2 (only tested on arm architecture) raspidef Raspberry Pi has only UART interface(s), but no RS232 control lines like DTR, RTS or so. This patch allows to use Raspberry's GPIOs as RS232 control lines for DDL, if the booster needs so. These changes are a minor part extracted from http://siggsoftware.ch/wordpress/srcpd-mit-mfx-und-anderen-erweiterungen/ ACKdetection This is for ACK detection on a NMRA DCC programming track (using the Raspberry PI's GPIO defined as RI in raspidefs). This is still a bit experimental, because I don't get out ACKs from my locomotive decoders in all cases. These patches are tested only on a Raspberry Pi, but should work for other Linux'es too, as far as not indicated otherwise above. Bernd |
|
From: Simon A. <sim...@gm...> - 2021-02-28 16:55:40
|
That sounds interesting, really looking forward to this patch. I ended up getting an old desktop PC with a proper RS232 interface up and running again after giving up on the Pi with a Tams B3 booster. I'll give it another shot with this release. On Wed, Feb 24, 2021 at 6:20 PM Bernd Wagner <f.j...@t-...> wrote: > > Am 24.02.21 um 17:04 schrieb Simon Ahrens: > > Has anybody been working towards a 2.1.6?> > > Dear all, > > I'm currently preparing the following Patches against Rel.2.1.5: > > i2c-23017 > This driver controls GAs (accessories) by the I/O ports of > MCP23017 16Bit-I/O-Expanders > driven by the i2c-dev interface of the Linux kernel (similar to > i2c-dev, but other hardware). > rs232speed > alternative method to improve NMRA DCC timing for the DDL driver > - works for newer Linux kernels using termios2 (only tested on arm > architecture) > raspidef > Raspberry Pi has only UART interface(s), but no RS232 control > lines like DTR, RTS or so. > This patch allows to use Raspberry's GPIOs as RS232 control lines > for DDL, if the booster needs so. > These changes are a minor part extracted from > > http://siggsoftware.ch/wordpress/srcpd-mit-mfx-und-anderen-erweiterungen/ > ACKdetection > This is for ACK detection on a NMRA DCC programming track (using > the Raspberry PI's GPIO defined as > RI in raspidefs). This is still a bit experimental, because I > don't get out ACKs from my locomotive > decoders in all cases. > > These patches are tested only on a Raspberry Pi, but should work for other > Linux'es too, as far as not indicated > otherwise above. > > Bernd > > > _______________________________________________ > Srcpd-devel mailing list > Src...@li... > https://lists.sourceforge.net/lists/listinfo/srcpd-devel > |
Thanks for helping keep SourceForge clean.
X