Serial Device Endpoint parameter summary

[benkot]

Tim you should add this to the summary text of these parameters for the next time you update the library

public SerialDeviceEndpoint(string portName: [int baudRate = 9600], [System.IO.Ports.Parity parity = 0], [int dataBits = 8], [System.IO.Ports.StopBits stopBits = 1], [bool dtrEnable = True], [bool rtsEnable = True], [System.IO.Ports.Handshake handshake = 0])

Parameters:

portName: Name of the port, COMx where x is an integer. baudRate: The baud rate. Optional; default is 9600. parity: The parity bit type. Optional; default is System.IO.Ports.Parity.None. dataBits: The number of data bits. Optional; default is 8. stopBits: The number stop bits. Optional; default is 1. dtrEnable: Indicates whether the DTR signal should be asserted or negated. Optional; default is true. rtsEnable: Indicates whether the RTS signal should be asserted or negated. Optional; default is true handshake: The serial handshake method (default: None)

Note what is not stated is what will dtrEnable and rtsEnable take as valid strings. Tim you should add this to the summary text of these parameters for the next time you update the library

dtrEnable accepts DTR or NoDTR rtsEnable accepts RTS or NoRTS These are the only ones which I was able to discern it does not take !DTR or !RTS or NDTR or NRTS which are common negated indicators

I'm not sure what is acceptable Handshake strings for the different types of handshake methods

You also identified there was a bug related to this Normally you could figure out what a connection string looks like by creating and endpoint manually, passing in all the parameter values in the contructor, then printint the created object. The ToString method should then print out the exact connection string you'd need to store in your settings to recreate that configuration in the future. However, the DTR and RTS parameters have been omitted from SerialDeviceEndpoint, so that's a formatting bug.

[benkot]

Actually it looks like there are two seperate issues. The one where I found the issue was using ChannelFactory.FromConnectionString(connection string). So I don't know if this connection string is directly related to Serial Device Endpoint or Serial communications channel.

Next thing that I would like to do is take a packet that has been received serially and then send it out via probably a UDP network packt. So need a UDP packet transmitter and receiver. It looks very similar to serial data that it may not be robust but probably reactive coms can manage the issue. This way I could take serial data and transfer it out on network and then use same software but accept a input conection via UDP. I only need one way communication. Transmit status packet from weather sensor.

[NameOfTheDragon]

Actually it looks like there are two seperate issues.

I agree, and it's best to create a completely separate enhancement request for that. It becomes too difficult to manage things if multiple issues are all crunched up together.

Regarding the serial endpoint parameters, I would suggest that you probably shouldn't be creating your connection strings manually and therefore the exact syntax shouldn't be interesting to you. I have added guidance to the documentation in SerialDeviceEndpoint.FromConnectionString() which is reproduced below. However, there is a bug in the endpoint class that currently prevents you from following that advice. This will be corrected shortly and I'll provide an integration build for you to try.

Guidance follows.

Remarks

Valid connection strings must match the following regular expression grammar:

^((COM|com)\d{1,3})(:((\d{3,7})(,(None|Even|Odd|Mark|Space))?(,(7|8))?(,(Zero|OnePointFive|One|Two))?(,(nodtr|dtr))?(,(norts|rts))?(,(None|XOnXOff|RequestToSend|RequestToSendXOnXOff))?)?)?$

Since that is a rather unfriendly expression to human eyes, one way to determine correct connection string syntax is to create a specimen endpoint, passing in the required configuration as constructor parameters. Then, write the object to an output stream or examine the DeviceAddress property. The ToString() method of any endpoint will write out a syntactically correct connection string. There are many ways to accomplish this. For example, you can use the C# Interactive window in Visual Studio, write a unit test, use Windows PowerShell or an utility such as LINQPad. In LINQPad, the following fragment will suffice:

var endpoint = new SerialDeviceEndpoint("COM1"); // Pass in whatever parameters you need
endpoint.Dump();

It is probably best to avoid creating connection strings directly as this will tend to be error prone, especially if it is from user-supplied input. Instead, create a user interface that gathers all of the serial parameters from the user. For an ASCOM driver, this will likely be part of the Setup Dialog. Save all the user-supplied data in your settings. Then generate a connection string by creating a SerialDeviceEndpoint, passing the user settings in as constructor parameters. Finally, use ToString or theDeviceEndpoint.DeviceAddress` property to retrieve the corresponding connection string. The connection string can either be saved along with user settings and used 'as-is' in the next session, or it can be dynamically regenerated on demand using the above technique - the choice is yours. It is also up to you whether or not you decide to make the connection string visible to the user.

[NameOfTheDragon]

There's a NuGet package on the Tigra Astronomy developer feed at https://www.myget.org/feed/tigra-astronomy/package/nuget/TA.Ascom.ReactiveCommunications/1.3.0-alpha0010

If you would care to try it, the feed URL (for adding to Visual Studio) is: https://www.myget.org/F/tigra-astronomy/api/v3/index.json

Note: it is now dual-targetted to .NET Framework 4.7.2 and NETStandard 2.0

[benkot]

Hi Tim,

Current plan is user only selects the comm port from auto poplulated pull down list available on system. For my weather sensor the DTR and NoDTR, RTS and NoRTS is use to toggle the device from programming mode to user output mode. All other port configuration parameters are not user selectable. I think the Regex description would be enough to decorate the method so that it pops up on intellisense for the connection string parameter.

[NameOfTheDragon]

@benkot Would you care to have a look at the release-candidate for the next release? See https://github.com/Tigra-Astronomy/TA.ReactiveCommunications/pull/12

It's supposed to be a non-breaking change so I'd be really interested to hear whether that is really true!

Lots of changes to how logging works, mainly.

The SerialDeviceEndpoint.FromConnectionString() method has been changed so that it returns a SerialDeviceEndpoint and not a DeviceEndpoint. So you can now new one up and set all the properties how you want them, then use ToString() to see what the connection string should look like.

I'll be merging this pull request in the next couple of days.

[benkot]

Hi Tim,

I’ve been out of action on the programming project for 10-12 weeks now. Spring hits and my honey do list around the yard grows proportionally over the winter. Work also takes me into planning summer activity stages and takes me away from home. I saw your earlier email but was in work travel status and didn’t get a chance to respond. So Sorry!. It’s pretty hard to take the project with me when I travel. I will see if I can get some time this week. I really appreciate the contact and update notification.

I want to put my project out as open source. Honestly I think we need more examples of how different implementation can utilize your reactive comm and get better buy on. I keep trying to work through and adapt your digital domeworks examples only to find there is something else I haven’t quite addressed. I was actually just about to go and build a data simulator like you had to simulate the data flow rather than the real data, to ease the development routine. I had a simple data simulator in my earlier version but it was done at an higher level. I will get there. Learning new ways is challenging but also rewarding at the same time.

Todd

From: Tim Long Sent: Sunday, July 19, 2020 6:36 PM To: Tigra-Astronomy/TA.ReactiveCommunications Cc: benkot ; Mention Subject: Re: [Tigra-Astronomy/TA.ReactiveCommunications] Serial Device Endpoint parameter summary (#5)

@benkot Would you care to have a look at the release-candidate for the next release? See #12

It's supposed to be a non-breaking change so I'd be really interested to hear whether that is really true!

Lots of changes to how logging works, mainly.

The SerialDeviceEndpoint.FromConnectionString() method has been changed so that it returns a SerialDeviceEndpoint and not a DeviceEndpoint. So you can now new one up and set all the properties how you want them, then use ToString() to see what the connection string should look like.

I'll be merging this pull request in the next couple of days.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[benkot]

Hi Tim,

Looks like the issue is fixed. Sorry I hadn’t been back into the coding until now.

Todd

From: Tim Long Sent: Sunday, July 19, 2020 6:36 PM To: Tigra-Astronomy/TA.ReactiveCommunications Cc: benkot ; Mention Subject: Re: [Tigra-Astronomy/TA.ReactiveCommunications] Serial Device Endpoint parameter summary (#5)

@benkot Would you care to have a look at the release-candidate for the next release? See #12

It's supposed to be a non-breaking change so I'd be really interested to hear whether that is really true!

Lots of changes to how logging works, mainly.

The SerialDeviceEndpoint.FromConnectionString() method has been changed so that it returns a SerialDeviceEndpoint and not a DeviceEndpoint. So you can now new one up and set all the properties how you want them, then use ToString() to see what the connection string should look like.

I'll be merging this pull request in the next couple of days.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.