About the Ascom driver (meridian flip)

[grozmaistor]

Hello Kevin, I have found your mini Arduino project and I was tempted to play with it so I have built everything as described. My prototype got nicely built and works pretty fine.

As you know if you do a meridian flip the declination axis' up/down become totally the opposite. So I've added little more code to the Arduino sketch a (MFLIP# command) so I can exchange the pins of the Dec axis, whenever I want. In order to do it via the COM I must disconnect the arduino in SkyCharts and then send the MFLIP# command. But after I connect it in SkyCharts again there nothing is changed. It looks like one just has started it. I assume this comes from the driver. It probably restarts the Arduino on each connect in SkyCharts. Is this the reason and can we change it?

Kind Regards Grozdan

[kevinferrare]

Hello Grozdan,

Sorry for the late reply, I just realized that github doesn't send any email notification for issues. It is interesting that you are trying to implement meridian flip.

As you noticed, the Arduino is restarted on every connection, here is how to disable this behaviour in hardware: http://playground.arduino.cc/Main/DisablingAutoResetOnSerialConnection

I think it would be better to implement the mflip operation in the ASCOM driver. I will add it on the TODO list (and probably implement it once I get the time to use the telescope again ...).

Regards, Kevin

[grozmaistor]

Hello Kevin, I have made a change in the driver you supplied and I added a checkbox to mark the meridian flip by hand. This sends a "MFLIP" command to the arduino in order to swith the pins for DEC. It was the easiest way at the moment.

But I am facing a serious problem with something else. I am trying to connect the device via bluetooth. The bluetooth is HC-05 and I have changed the baud rate of it to 56700 no parity, one stop bit. When I am connecting Cartes du ciel via the bluettoth (let's say COM5 associated) the bluetooth device connects itself and changes blinking. So it is connected. But after a few seconds a message appears saying that: "ERROR: Timed out waiting for received data!" And I don't know why this happens. I guess it is in the driver. For instance if I use TerraTerm to make bluetooth connection it is OK. But via Cartes du ciel it isn't.

Any ideas :-) will be appreciated.

Best Regards.

[kevinferrare]

Hello Grozdan,

Connecting the device via bluetooth is very interesting, it has a great potential to help reducing the number of cables lying in the dark around the telescope :) I will buy an HC-05 to see if I can get it work too. It would be very good if the arduino and HC-05 could be powered from the same battery as the engines (would reduce the number of cables futher).

Meanwhile, if you want to fiddle with the connection, it is handled with ASCOM standard serial toolbox. This is all done in ASCOMDriver/ArduinoST4Driver/ArduinoST4Driver/DeviceController.cs (Connect method).

Regarding MFLIP, I think there is also a need for complete control inversion, for users located in the southern hemisphere who don't have a switch for this on their devices (got an email from someone in this situation a few weeks ago). I will try to implement it in the driver directly once I have a minute ...

Regards, Kevin

[grozmaistor]

Hello Kevin, The meridian flip is currently a checkbox in the driver config popup.

I played yesterday with the hc-05 serial connection instead of usb cable. But I tryied with phd guiding software and it works pretty good. So phd communicates well with the controller trough the ascom driver. But if we try Cartes du ciel and it fails of course and then we try phd, then phd also fails and we need to restart the arduino device. I think it is something very little to be changed but I don't know yet what.

[kevinferrare]

I won't be able to confirm it until I get the hardware, but I think I know why it fails with HC-05.

By default, the arduino is reset on each serial connection, so the driver has to wait for the arduino to initialize before attempting to talk to it. Concretely, the driver listens on the serial port until it gets an "INITIALIZED#" message from the arduino.

If the HC-05 never resets the arduino upon reconnect, there will be cases when the driver will never receive anything, and so will consider that the arduino is not working properly.

The way to fix this would be to catch whatever exception is generated, to wait some seconds, and to try to connect anyway.

The code that does this is at DeviceController.cs:66

[kevinferrare]

Regarding meridian flip, I started to code it in the driver (branch hemispheres_and_meridian_flip_handling). It has to be implemented driver side in order to take in account the potentially different slew rates of the DEC+/DEC- moves in the position calculation (for GOTO).

[grozmaistor]

Hello Kevin, Thank you for the comments. In my last tries I succeeded to run the arduino from Cartes du ciel via bluetooth but it seems the problem is after disconnecting and trying to connect again. After that the driver definetely fails. So hopefully Cartes du ciel can work. I'll check the driver code, where you suggested.

[kevinferrare]

I made the modification I think could solve the connectivity issue with bluetooth, here it is if you want to try: https://drive.google.com/file/d/0B04IJvbw0nqmNFlBa3AxSlcxZTQ/view?usp=sharing

If you tell me that this is working fine, I will include it in the next release

[grozmaistor]

Hello Kevin, I have tested the driver and unfortunately new behaveiour is totally the same as with the old driver. So this version does nto solve the problem. But I think may be we can not fix it in the driver because in Nano I use for Bluetooth connection SoftwareSerial and I think it does not reset the arduino when connection is opened. It is a very strange behaveiour that I noticed when conencting from the serial console via usb and via bluetooth. Here are some case:

1. Connect with serial console from usb cable and then disconnect. Do this 4 times. So on the serial copnsole you have four times written: #INITIALIZED and four times the setup() is called. In my setup I start Software Serial for the bluetooth and send also #Initialized on the BT serial line.
2. Try to connect from the serial console on the com port for bluetooth. As a result the bluetooth leds show that the bluetooth is conencted but serial console does not receive: #INITIALIZED message.
3. by hand senn CONNECT# command. As a result the serial console shows 4 times #INITIALIZED and then #OK (for CONNECT).
4. While the serial console is connected to the bluetooth com port press the reset button of arduino - Result is that arduino is of course reset and the console receives #INITIALIZED message via bluetooth.

What I think is this: The serial connection via bluetooth and seen from arduino side is that connection only from arduino to bluetooth and not to the Computer. That's why as many times as we want to connect/disconnect the computer from/to bluetooth this has no effect on the reset and setup() method call. And only after we feed the controller with a command to process then is sends #OK and the cached #INITIALIZED messages are sent too.
On the other side if we establish serial connection via usb then each time when the serial console is opened(we do not unplug the cable) the arduino is reset.

Fortunately a hard reset from the reset button solves the bluetooth problem. Or jus unplug and plug it from power.

[grozmaistor]

I need to check this with the Arduino-mega with more hardware serial lines where both usb and bluetooth will be connected. Just to have more info on the case.

[kevinferrare]

Thanks for trying, and for your extensive analysis!

Another option would maybe be to wire the arduino and the HC-05 so that a reset is performed on each connection, like this: http://i.solidfiles.net/4c042229f9.png Did you try this approach?

This could make an unmodified driver work for both USB and bluetooth connections. I will try to play with the HC-05 as soon as I have it.

The driver waits for the arduino to say "#INITIALIZED" in order to accelerate the connection process, else it would have to wait until timeout before sending any command because it can't know when the board has finished booting.

[grozmaistor]

Hello, I am sorry for replying quite late but I didn't have time. I hav to disappoint you. I tried the provided scheme with 100nF capacitor and 10K resistor the bluetooth's behaviour is the same but now the USB serial connection doesn't want to show the INITIALIZED# message when connected. The RX pin of the bluetooth is conencted directly to TX pin of arduino without a voltage devider as there is a logic level on the bluetooth and BT functions normally. I can make a try anyway with extra voltage devider if there is some theoretical possibility that this lack makes the whole mess.

[feilimb]

Hi Kevin

Many thanks for your work on this so far and apologies for hi-jacking this issue when this is more of a question / idea but in a similar vein to bluetooth mentioned above:

I was considering adapting your Arduino code / Ascom driver code for use with an ESP-8266 (Wifi SOC) module which can also be programmed with the Arduino IDE. As the module is Wifi, the idea would be to place it on the scope, and program it to listen for UDP messages as opposed to serial commands for RA+/- etc. A web server running on the module could also offer eg. ability to control scope from a client on the same network via a web interface.

Whereas I am familiar with Arduino programming to some extent, I have never programmed Windows COM drivers. Can you tell me whether the full Visual Studio tool-chain is necessary to rebuild an adapted driver or might you know if there is a more light-weight approach to a rebuild.

[kevinferrare]

@grozmaistor Hello,

I just received my HC-05 module, and I am able to reproduce the problem you noticed. The root cause seems to be this error thrown by ASCOM serial code:

ASCOM.DriverAccessCOMException was unhandled
Message: An unhandled exception of type 'ASCOM.DriverAccessCOMException' occurred in ASCOM.DriverAccess.dll
Additional information: Timed out waiting for received data

Unfortunatly, I couldn't find a way to recover from it in the driver. I will try to use .net standard serial connection as a workaround.

[kevinferrare]

@feilimb Hello,

I am very curious to see if you can manage to adapt the code to the ESP-8266! It seems a bit less convenient than bluetooth because you would need to setup a wifi network to connect to your telescope, I don't want to imagine doing this outside in a dark cold night :)

Modifying the driver is relatively straightforward once you have the development environment set up. You will need a development environment supported by ASCOM since the driver relies on this framework, and as far as I am aware, the only way to do C# with ASCOM is with visual studio (I use the free edition of visual studio 2015). You can start with the small tutorial on their website: http://www.ascom-standards.org/Developer/DriverImpl.htm

[kevinferrare]

@grozmaistor I was able to connect without failure several times in a row via bluetooth with this version of the driver: https://drive.google.com/open?id=0B04IJvbw0nqmZVFFal9COEhERnc It assumes that the serial connection is 9600 bauds because this is what seems to be the default setup on my HC-05 module.

I didn't check whether the telescope was moving properly or not.

Could you check if this solves the problem on your side?

[feilimb]

@kevinferrare thanks Kevin, with the ESP-8266 modules you can configure the module to act as a wireless access point, meaning a client (laptop) can just search for available access points and connect as though it was a standard wifi router - this would be more suitable out in the field.

If I get the project up and running I'll fork this repo and let you know! Many thanks for the ascom driver development tips too.