Menu
▾
▴
srcpd-devel — Developers only
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(80) |
Feb
(10) |
Mar
|
Apr
(13) |
May
|
Jun
|
Jul
|
Aug
(22) |
Sep
(37) |
Oct
(27) |
Nov
(20) |
Dec
(2) |
| 2004 |
Jan
(20) |
Feb
(35) |
Mar
(17) |
Apr
(15) |
May
(44) |
Jun
(9) |
Jul
(14) |
Aug
(4) |
Sep
(1) |
Oct
(17) |
Nov
(23) |
Dec
(5) |
| 2005 |
Jan
(13) |
Feb
(4) |
Mar
(49) |
Apr
(30) |
May
(13) |
Jun
(24) |
Jul
(26) |
Aug
(13) |
Sep
(3) |
Oct
(38) |
Nov
(19) |
Dec
(68) |
| 2006 |
Jan
(14) |
Feb
(6) |
Mar
(12) |
Apr
(4) |
May
(16) |
Jun
(49) |
Jul
(40) |
Aug
(8) |
Sep
(2) |
Oct
(4) |
Nov
(16) |
Dec
(42) |
| 2007 |
Jan
(65) |
Feb
(36) |
Mar
(18) |
Apr
(70) |
May
(2) |
Jun
|
Jul
(9) |
Aug
(13) |
Sep
(13) |
Oct
(33) |
Nov
(173) |
Dec
(116) |
| 2008 |
Jan
(217) |
Feb
(5) |
Mar
(22) |
Apr
(1) |
May
|
Jun
(7) |
Jul
(4) |
Aug
(30) |
Sep
(6) |
Oct
(8) |
Nov
(17) |
Dec
(15) |
| 2009 |
Jan
(117) |
Feb
(2) |
Mar
(1) |
Apr
(24) |
May
(18) |
Jun
(30) |
Jul
(13) |
Aug
(51) |
Sep
(2) |
Oct
(5) |
Nov
(10) |
Dec
(47) |
| 2010 |
Jan
(9) |
Feb
(35) |
Mar
(84) |
Apr
|
May
(2) |
Jun
(8) |
Jul
(6) |
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(3) |
Dec
(24) |
| 2011 |
Jan
(7) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(10) |
Aug
(26) |
Sep
|
Oct
(12) |
Nov
(2) |
Dec
(4) |
| 2012 |
Jan
(38) |
Feb
(28) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(60) |
Nov
(13) |
Dec
|
| 2013 |
Jan
(32) |
Feb
(1) |
Mar
(16) |
Apr
(4) |
May
(7) |
Jun
(6) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
| 2014 |
Jan
(110) |
Feb
(38) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
(1) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(2) |
Mar
(11) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
(26) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(13) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(46) |
Apr
(22) |
May
(12) |
Jun
(12) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
(5) |
Feb
(8) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2023 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Jeroen V. <je...@vr...> - 2024-10-29 21:43:28
|
Hi, Recently I have been adding support for extended accessory decoders to my SRCP implementation. It allows the use of aspects for accessories. I have made an RFC to add support for extended accessories to the protocol (I took the 0.8.5-wip version as base) http://video.vreeken.net/train/srcp-ga-dccext.html I still have not figured out how to add support for (extended) accessory CV setting in the SM group, but wanted to share my GA extensions anyway. Regards, Jeroen |
|
From: Guido S. <gui...@gm...> - 2024-05-03 07:01:37
|
Dear all,
due to some feedback of srcpd users some erros could be fixed, so time for
new release.
Here are the release notes:
srcpd-2.1.7 (2024-05-03)
Fixed Bugs
o Remove usage of MAXPATHLEN to provide HURD compatibility
o Fix name spelling errors
o Include stdlib.h to fix gcc 14 compiler warning
o Replace SYSFS by ATTRS in udev rules files
Please find the source code files at the usual place:
https://sourceforge.net/projects/srcpd/files/srcpd/2.1.7/
Guido
--
http://wie-im-flug.net/
http://www.lug-burghausen.org/
|
|
From: Guido S. <gui...@gm...> - 2024-02-02 07:23:48
|
Hi all, the last days I went through the bugs our project page lists here: https://sourceforge.net/p/srcpd/bugs/ Some were quite old but most of them are solved meanwhile. There is still one remaining (#10) which deals with a kind of unclear formulation in the SRCP protocoll documentation regarding the TIME device. Here at section 2.6 you can find the discussed wording: https://srcpd.sourceforge.net/srcp/srcp-085-wip.html#Introduction For my understanding it would make sense to add the following to "System Time": This is the default and fallback time source. Are there any comments or other ideas? Chears Guido -- http://wie-im-flug.net/ http://www.lug-burghausen.org/ |
|
From: Guido S. <gui...@gm...> - 2023-03-05 08:02:45
|
Dear all,
due to some feedback of srcpd users some erros could be fixed, so time for
new release.
Here are the release notes:
srcpd-2.1.6 (2023-03-05)
Fixed Bugs
o Implement GL locks on item level (patch provided by Simon Ahrens)
o Spelling errors in source code and man pages (hint by Hilmar
Preuße).
General Changes
o Small internal cleanups
Please find the source code files at the usual place:
https://sourceforge.net/projects/srcpd/files/srcpd/2.1.6/
Guido
--
http://wie-im-flug.net/
http://www.lug-burghausen.org/
|
|
From: Ralf K. <Ral...@gm...> - 2023-01-24 11:00:09
|
Am 14.04.21 um 13:19 schrieb Bernd Wagner: > I have submitted the following patches: > > 14 bw-cumulative patch for patches 11-13 based on 2.1.5 > This is just technically in order to avoid problems when merging. > > 15 bw-ACKdetection for the ddl driver, based on Patch 14 > > If at least one of the (newly introduced) parameters scanACK_delay, > handleACK_delay, ACK_samplingtime or ACK_debouncer is set, a more > elaborated sampling of the RI control line is done. This is aimed > for the use with a simple electronic circuit like > https://www.stacken.kth.se/~haba/slamra/dcc/ackdetect/ > and/or for the case of deviating decoder timing. ich habe Deinen Patch "bw-ACKdetection" bei mir ins srcpd 2.1.5 übernommen und die folgende Programmiergleisschaltung aufgebaut, den Kollektor vom Transistor habe ich an einen Optokoppler CNY 17 angeschlossen. Anstatt der 30 Ohm verwende ich 39 Ohm http://www.strukto.de/tt/digital-Dateien/Prog-gleis-DDL-Vogt-IT.jpg Zum Auslesen der CVs verwende ich den nmra-programmer. Die meisten Lokdekoder sind ESU LokPilot DCC V 2 - 4 Irgendwas passt noch nicht so richtig, das Bit7 der ausgelesenen CVs ist immer 1. Kann es evtl sein, daß bei den Parametern scanACK_delay, handleACK_delay, ACK_samplingtime und ACK_debouncer bei mir die Defaultwerte nicht passen? Ich möchte nun die einfachere Schaltung verwenden https://www.stacken.kth.se/~haba/slamra/dcc/ackdetect/ Kann ich da anstatt des PC817 auch den AC-Optokoppler PC814 verwenden? Gruß Ralf |
|
From: Simon A. <sim...@gm...> - 2021-10-18 13:39:35
|
P.S.: I assume the relevant check happens in int init_bus_S88(bus_t busnumber), ddl-s88.c lines 278 ff. On Mon, Oct 18, 2021 at 2:36 PM Simon Ahrens <sim...@gm...> wrote: > Dear all, > > trying to use an S88 bus via a PCI parallel port extension, I've noticed > that srcpd will currently reject any other values for the IO port than the > legacy 0x278, 0x378 and 0x3bc (the old parport (Linux) / LPT (Windows) > addresses. > > However, if you use anything but built-in parallel ports, your adapter > will probably provide you with different (fixed) IO ports. I see no reason > to keep the check for the old legacy addresses either. > > I've found a Rocrail forum thread from 10 years ago where someone > describes the same issue. Rocrail has since changed this sanity check and > now allows any address. > > Do you see a way to fix this for srcpd as well? > > Best regards, > Simon > |
|
From: Simon A. <sim...@gm...> - 2021-10-18 12:36:54
|
Dear all, trying to use an S88 bus via a PCI parallel port extension, I've noticed that srcpd will currently reject any other values for the IO port than the legacy 0x278, 0x378 and 0x3bc (the old parport (Linux) / LPT (Windows) addresses. However, if you use anything but built-in parallel ports, your adapter will probably provide you with different (fixed) IO ports. I see no reason to keep the check for the old legacy addresses either. I've found a Rocrail forum thread from 10 years ago where someone describes the same issue. Rocrail has since changed this sanity check and now allows any address. Do you see a way to fix this for srcpd as well? Best regards, Simon |
|
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-04-14 11:46:37
|
I have submitted the following patches:
14 bw-cumulative patch for patches 11-13 based on 2.1.5
This is just technically in order to avoid problems when merging.
15 bw-ACKdetection for the ddl driver, based on Patch 14
If at least one of the (newly introduced) parameters scanACK_delay,
handleACK_delay, ACK_samplingtime or ACK_debouncer is set, a more
elaborated sampling of the RI control line is done. This is aimed
for the use with a simple electronic circuit like
https://www.stacken.kth.se/~haba/slamra/dcc/ackdetect/
and/or for the case of deviating decoder timing.
see description in man srcpd.conf.5 in the patch
This patch is based on Patch 14 to avoid merging problems (but
shouldn't depend functionally).
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-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: 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 > |
|
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: Guido S. <gui...@gm...> - 2021-02-24 17:08:39
|
<html> <head> <meta name="viewport" content="width=device-width"> <meta http-equiv="Content-Type" content="text/vnd.ui.insecure+html;charset=utf-8"> </head> <body style="overflow-wrap:break-word; word-break: break-word;"><div class="mail_android_message" style="line-height: 1; padding: 0.5em">Hi Simon,<br/>make a patch and add it to the projekt page so we can test it.<br/>Guido<br/><br/>--<br/><a href="http://wie-im-flug.net/">http://wie-im-flug.net/</a></div><div class="mail_android_quote" style="line-height: 1; padding: 0.3em"><html><body>Am 24.02.21, 17:04 schrieb Simon Ahrens <sim...@gm...>:</body></html><blockquote class="gmail_quote" style="margin: 0.8ex 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div dir="ltr"> <div> Alright, looks like I got it working. GL locking is now glstate-based in my local copy and timed locking of GLs is working. <br> </div> <div> <br> </div> <div> Is anybody interested in the changes, as simple as they may be? Has anybody been working towards a 2.1.6? </div> <div> <br> </div> <div> Best regards, </div> <div> Simon <br> </div> </div> <br> <div class="gmail_quote"> <div class="gmail_attr" dir="ltr"> On Tue, Feb 23, 2021 at 8:44 PM Simon Ahrens <<a href="mailto:sim...@gm...">sim...@gm...</a>> wrote: <br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> 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 "<span style="color:rgb(128,0,0)">.gastate</span>[<span style="color:rgb(9,46,100)">addr</span>]". Alright... I'll dig deeper in the next weeks :) <br> </div> <br> <div class="gmail_quote"> <div class="gmail_attr" dir="ltr"> On Tue, Feb 23, 2021 at 7:39 PM Guido Scholz <<a href="mailto:gui...@gm...">gui...@gm...</a>> wrote: <br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div> <div> Am 23.02.21 um 17:03 schrieb Simon Ahrens: <br> </div> <blockquote> <div dir="ltr"> <div> Dear all, </div> </div> </blockquote> <p>Hi Simon,<br> </p> <blockquote> <div dir="ltr"> 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): </div> </blockquote> [...] <br> <blockquote> <div dir="ltr"> <div> <p style="margin:0px;text-indent:0px;white-space:pre-wrap"><span style="color:rgb(0,26,134)">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).</span></p> </div> </div> </blockquote> <p>Locks are not heavily tested. I don't know if there is any SRCP client which supports this feature.</p> <p>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.</p> <p>Guido</p> <p><br> </p> </div> _______________________________________________ <br> Srcpd-devel mailing list <br> <a href="mailto:Src...@li...">Src...@li...</a> <br> <a href="https://lists.sourceforge.net/lists/listinfo/srcpd-devel">https://lists.sourceforge.net/lists/listinfo/srcpd-devel</a> <br> </blockquote> </div> </blockquote> </div> _______________________________________________ Srcpd-devel mailing list Src...@li... https://lists.sourceforge.net/lists/listinfo/srcpd-devel </blockquote></div></body> </html> |
|
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: 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-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: 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 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: Bernd W. <f.j...@t-...> - 2021-01-27 22:46:55
|
Hallo Guido, ich habe deine Mail nicht über Sourceforge bekommen. Danke für deine direkte Mail. srcpd-devel habe ich jetzt abonniert. zu: > 2) Lade deine Änderungen bitte als Patches gegen die aktuelle Version > hoch: https://sourceforge.net/p/srcpd/patches/ > Bitte pro Thema einen eigenen Patch, nicht alles an einem Stück. Das > erleichtert das Korrekturlesen. Die Patches werde ich dann nach und nach schicken - das braucht ja dann etwas Vorbereitung auf meinem lokalen svn und Sorgfalt bei der Vorbereitung der Patches und Trennung der Themen. Auch möchte ich vorher die Abstimmung mit siggsoftware.ch suchen, zumal die Patches auf seiner Version aufbauen. Historisch handelt es sich um aufeinander aufbauende Patches auf Basis von 2.1.1 - ich habe mir noch nicht überlegt, ob und wie das "als Patches gegen die aktuelle Version" und nach Themen getrennt Review-fähig aussehen könnte. Für mich ist es ein Fork, der sich getrennt weiterentwickelt hat. Viele Grüße Bernd Wagner |
|
From: Guido S. <gui...@gm...> - 2021-01-27 05:38:30
|
Am 26.01.21 um 00:56 schrieb Ralf Kleemann: > Hallo, Hallo Ralf, > Nun weiß ich aber nicht wo ich das -li2c eintragen muß damit es beim > kompilieren verwendet wird. > du musst in der Datei configure.ac auf das Vorhandensein der libi2c prüfen, damit der Linker diese Konfiguration mitgeteilt bekommt, z. B in der Art: AC_CHECK_LIB(i2c, i2c_smbus_write_byte, , AC_MSG_ERROR(lib i2c is missing)) Ab Zeile 180 wäre da Platz für. Genau genommen muss das so eingebaut werden, das die Prüfung nur bei nicht abgeschalteter Unterstützung der i2c Funktionalität stattfindet, für einen ersten Test ist das aber nicht relevant. Nach der Änderung folgendes ausführen: autoreconf Dann das configure Skript aufrufen.. Gruß Guido |
|
From: Ralf K. <ral...@gm...> - 2021-01-26 00:17:35
|
Hallo,
ich verwende als Hardware einen Raspberry Pi B+, ich habe einen tams DCC Booster an die Serielle angeschlossen.
Ich habe auch Interesse an der Interpretation des ACK-Signals vom Programmiergleis.
Ich würde auch gerne Rückmeldekontakte anschließen. Anstatt dem s88-Bus würde ich gerne i2c verwenden.
Ich möchte dazu gerne einen Maple Mini per i2c an den Raspi anschliessen.
An den Maple Mini kann ich dann die Rückmeldekontakte direkt anschliessen oder über einen Bus oder ähnliches.
Ich habe ein Testprogramm geschrieben, damit ich es kompilieren kann muss ich beim gcc "-li2c" anhängen
gcc -o i2ctest i2ctest.c -li2c
Nun weiß ich aber nicht wo ich das -li2c eintragen muß damit es beim kompilieren verwendet wird.
Der Einfachheit halber möchte ich die i2c Routinen erstmal in die ddl-s88.c einbauen
i2ctest.c
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/i2c-dev.h>
#include <i2c/smbus.h>
#define addr 4
#define anz 5
int main()
{
int file;
__s32 res;
char filename[20] = "/dev/i2c-1";
printf("i2ctest\n");
file = open(filename, O_RDWR);
if (file < 0) {
printf("error open i2c\n");
exit(1);
}
if (ioctl(file, I2C_SLAVE, addr) < 0) {
printf("error addr i2c\n");
exit(1);
}
res = i2c_smbus_write_byte(file, 30);
for (unsigned int n = 0; n <= anz; n++) {
res = i2c_smbus_read_byte(file);
if (res >= 0) {
printf("ret: %ld\n", res);
}
}
return 0;
}
Gruß Ralf
|
|
From: Ralf K. <ral...@gm...> - 2021-01-25 23:56:17
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hallo,</div>
<div> </div>
<div>ich verwende als Hardware einen Raspberry Pi B+, ich habe einen tams DCC Booster an die Serielle angeschlossen.</div>
<div>Ich habe auch Interesse an der Interpretation des ACK-Signals vom Programmiergleis.</div>
<div> </div>
<div>Ich würde auch gerne Rückmeldekontakte anschließen. Anstatt dem s88-Bus würde ich gerne i2c verwenden.</div>
<div>Ich möchte dazu gerne einen Maple Mini per i2c an den Raspi anschliessen.</div>
<div>An den Maple Mini kann ich dann die Rückmeldekontakte direkt anschliessen oder über einen Bus oder ähnliches.</div>
<div> </div>
<div>Ich habe ein Testprogramm geschrieben, damit ich es kompilieren kann muss ich beim gcc "-li2c" anhängen</div>
<div>gcc -o i2ctest i2ctest.c -li2c</div>
<div> </div>
<div>Nun weiß ich aber nicht wo ich das -li2c eintragen muß damit es beim kompilieren verwendet wird.</div>
<div>Der Einfachheit halber möchte ich die i2c Routinen erstmal in die ddl-s88.c einbauen</div>
<div> </div>
<div>i2ctest.c</div>
<div> </div>
<div>
<div>#include <stdlib.h><br/>
#include <stdio.h><br/>
#include <fcntl.h><br/>
#include <sys/ioctl.h><br/>
#include <linux/i2c-dev.h><br/>
#include <i2c/smbus.h></div>
<div>#define addr 4<br/>
#define anz 5</div>
<div> </div>
<div>int main()<br/>
{<br/>
int file;<br/>
__s32 res;<br/>
char filename[20] = "/dev/i2c-1";</div>
<div> </div>
<div> printf("i2ctest\n");</div>
<div> file = open(filename, O_RDWR);<br/>
if (file < 0) {<br/>
printf("error open i2c\n");<br/>
exit(1);<br/>
}</div>
<div> if (ioctl(file, I2C_SLAVE, addr) < 0) {<br/>
printf("error addr i2c\n");<br/>
exit(1);<br/>
}</div>
<div> res = i2c_smbus_write_byte(file, 30);<br/>
for (unsigned int n = 0; n <= anz; n++) {<br/>
res = i2c_smbus_read_byte(file);<br/>
if (res >= 0) {<br/>
printf("ret: %ld\n", res);<br/>
}<br/>
}</div>
<div> return 0;<br/>
}</div>
<div> </div>
<div>Gruß Ralf</div>
</div>
<div> </div></div></body></html>
|
|
From: Guido S. <gui...@gm...> - 2021-01-24 11:05:35
|
Hallo Bernd, danke für dein Anschreiben, Verbesserungsbeiträge sind jederzeit willkommen. Mein Vorschlag zum weiteren Vorgehen: 1) Abonniere bitte die "devel" Mailingliste (https://sourceforge.net/p/srcpd/mailman/), die weitere Diskussion kann dann dort ablaufen. 2) Lade deine Änderungen bitte als Patches gegen die aktuelle Version hoch: https://sourceforge.net/p/srcpd/patches/ Bitte pro Thema einen eigenen Patch, nicht alles an einem Stück. Das erleichtert das Korrekturlesen. Es gibt sicher Interessenten, die diese Änderungen gerne testen wollen. Ich habe die Mailingliste gleich mal mit in den Verteiler genommen. Gruß Guido Am 24.01.21 um 10:19 schrieb be...@us...: > > REPLY at https://sourceforge.net/u/berwag/profile/send_message > > ------------------------------------------------------------------------ > > Guten Tag Guido Scholz, > > Sie haben auf Sourceforge in jüngerer Zeit an srcpd gearbeitet. > > Ich möchte nach einem Branch und Schreibrechten auf dem > Sourceforge-Repository für die Einbringung folgender Varianten fragen: > > Ich habe bei mir srcpd in der Version von > http://siggsoftware.ch/wordpress/srcpd-mit-mfx-und-anderen-erweiterungen/ > im Einsatz. Diese Version wurde vom Inhaber dieser Website wohl etwa > beim srcpd Release-Stand 2.1.1 abgespalten und enthält Erweiterungen, > die speziell die Hardware des Raspberry Pi nutzen. Ich selbst habe > dazu noch bei mir lokal Erweiterungen auf Basis i2c-Bus zur > Ansteuerung von GAs sowie zur Interpretation des ACK-Signals vom > Programmiergleis vorgenommen. In den letzten Tagen habe ich bei mir > diese Version mit Ihrer Version 2.1.5 von Sourceforge gemerged. > > Ich würde diese Arbeiten gerne der Allgemeinheit zugänglich machen und > wieder in das ursprüngliche srcpd-Sourceforge-Repository zurückführen. > Wäre das in Ihrem/Eurem Sinne? > > Sicher sind an meiner Version noch Änderungen, Dokumentationsarbeiten > usw. vorzunehmen. Damit würde ich durchaus die Hoffnung verbinden, > dass eine Qualität erreicht werden kann, dass man den Branch wieder > auf den Hauptpfad zurückführen kann. Meine Test-Möglichkeiten sind > aber auf meine Raspberry-Pi-spezifische Bus-Hardware und die > Lok-Protokolle DCC und MM begrenzt. > > Bitte meine Anfrage gerne an die anderen srcpd-Administratoren > weitergeben, wenn dies zur Abstimmung sinnvoll ist. > > Wenn das Vorhaben Ihre/Eure Unterstützung findet, würde ich noch die > Abstimmung mit dem Inhaber von http://siggsoftware.ch/ (Daniel Sigg) > suchen, obgleich das aufgrund der GPL nicht obligatorisch wäre. > > Danke und Freundliche Grüße > > Bernd Wagner > f.j...@t-... > > ------------------------------------------------------------------------ > > This message was sent to you via the SourceForge web mail form. > Replying to this email will not work, please send a message to Bernd > Wagner at https://sourceforge.net/u/berwag/profile/send_message > |
|
From: Wolfgang B. <wol...@we...> - 2020-06-08 19:42:47
|
Hallo Josef, funktioniert (Mein Fehler: F2, nicht F1 weil Zaehlung bei F0 beginnt). Danke, Wolfgang On Mon, 2020-06-08 at 21:22 +0200, Josef Zinkernagel wrote: > Hallo Wolfgang > > nach meiner Meinung müsste es heißen: > > INIT 1 GL 45 M 2 14 5 Lok 45 im Märklin 2 Protokoll mit 14 > Fahrstufen und (max) 5 Funktionen > SET 1 GL 45 1 0 100 1 0 1 0 0 Lok 45 vorwärts (1) Fahrstufe 0 von > 100 % F0 = an, F1 = aus, F2 = an, F3+F4 = aus > > man kann sich auch auf die 14 Stufen beziehen, dann heißt es > SET 1 GL 45 1 0 14 1 0 1 0 0 > > Gruß > Josef > > Gesendet: Montag, 08. Juni 2020 um 21:01 Uhr > Von: "Wolfgang Buesser" <wol...@we...> > An: src...@li... > Betreff: Re: [Srcpd-devel] Telex-Kupplung > Danke, > > ja das is in der Tat eine delta. Da muesste man wohl umruesten (Motor > und Decoder). > > Die andere Lok hat aber einen 60902-decoder und eine Telexkupplung an > F2. Trotzdem gelingt es mir nicht, die anzusteuern. Vielleicht habt > Ihr > einen Tipp? > > Ich habe versucht: > init 1 gl 45 M 5 28 2 > set 1 gl 45 1 3 14 0 1 > > Mit F1 (hier 0) kann ich das Licht steuern. > F2 hat keine Wirkung. > > Ist M5 das richtige Protokoll? > Ist M 5(mit space richtig) > > Danke, > > Wolfgang > > > > _______________________________________________ > Srcpd-devel mailing list > Src...@li... > https://lists.sourceforge.net/lists/listinfo/srcpd-devel > _______________________________________________ > Srcpd-devel mailing list > Src...@li... > https://lists.sourceforge.net/lists/listinfo/srcpd-devel -- |
84 messages has been excluded from this view by a project administrator.
