K8055 Dome Diagnostics

Introduction

K8055 Dome Diagnostics is a diagnostic tool designed for those who utilise a Velleman K8055 or K8055N USB IO Board for telescope observatory dome automation.  It is specifically designed for use with the LesveDome solution (http://www.dppobservatory.net/) using the IO configuration from that solution.

One of the challenges of DIY Dome Automation is understanding whether or not the Azimuth sensor (some type of encoder either commercial or homemade) is operating correctly – particularly when using Gray code (2-bit quadrature) mode.  Traditionally this has required an oscilloscope to check the waveforms, but this method relies on the builder (often an astronomer and not an electronic enthusiast!) having access to and knowing how to use an oscilloscope.

More importantly, even with an oscilloscope, it’s not easy to tell what the K8055 board, and ultimately the LesveDome ASCOM driver, is reading from the encoder.  The problem is exacerbated by the fact that the driver needs to frequently “poll” the K8055 board to find the status of all the inputs, resulting in the input resolution of the system being relatively low.

Gray code pulses that are perfectly generated by the encoders may be misinterpreted by the LesveDome system if they are arriving too fast resulting in undersampling of the waveform.

K8055 Dome Diagnostics is designed to visualise both channels of the encoder input as well as the home sensor input to check for correct operation.  The tool also allows the user to calibrate the rotation of their dome without having to measure the physical parameters (this will be needed for dome slaving, but K8055 Dome Diagnostics removes the need to measure for the LesveDome azimuth sensor parameters)

K8055 Dome Diagnostics is ©2019 Steve Hennerley and whilst all rights to the software and underlying code are reserved, the application is available as FREE software for the benefit of the astronomical community, and users of the LesveDome system. You should not have paid for this software either individually or part of a bundle.

If you feel the software is beneficial to you and you would like to contribute to the author, the recommended way is to “buy me a coffee” from the following link https://buymeacoffee.com/SteveH

Download

You can download the latest version of K8055 Dome Diagnostics from the following OneDrive link:

K8055 Dome Diagnostics v1.0.7109 (1.5MB)

Changelog

Version 1.0.7109 – 19 June 2019

• NEW FEATURE – Gray  Code Pulse Speed Info now averages the last 10 Gray Code pulses rather than counting all pulses since last rest.  This prevents the data becoming erroneous after dome stops and starts moving.
• NEW FEATURE – The Gray Code indicator lights will now indicate RED if an “out of order” pulse is detected which may signify undersampling or other problem.  If this occurs, Gray Code Mode for the Parameter Calculator (below) is automatically disabled
• NEW FEATURE – The Parameter Calculator section now has an option for “Gray Code Mode” – this mode uses both sensors and increased (x4) resolution of Gray Code from both encoder sensors to calculate more accurate parameters.  If Gray Code Mode is off, the parameter calculator uses Sensor 1 data only as per previous versions
• BUGFIX – Home Sensor counter was staying at zero at startup or after Reset Counter was pressed until 2 home crossings or 10 counts were received.  This was a regression bug introduced in 1.0.7106 along with the software debounce function.

Version 1.0.7106 – 17 June 2019

• NEW FEATURE – Software Debounce for Home Sensor. The Parameter Calculator will now ignore any additional pulses to the home sensor after it is triggered, until 10 pulses are received on Sensor1.  This is to prevent switch contact issues at home crossing from interfering with the calculation

Version 1.0.7105 – 16 June 2019

• Initial Public Release

Documentation

Whilst there is not currently full documentation available for the software, the following instructions  should be enough to get you started:

• The two counters read inputs 1 & 5 which the two sensors on the azimuth wheel  (assuming a gray code setup) connect to
• The “counter” field is the number of times there has been a pulse (rising edge software wise – although electrically it is likely to have been to ground) since counter reset
• “Since Last Home” counts since we passed the home sensor (rising edge as well)
• The Gray Code indicator LEDs should rise or fall sequentially if we’re getting a good Gray Code pattern  (00,01,11,10)
  • If we don’t get a good pattern, the LEDs will illuminate RED
• Reset Counters zeros all the counters
• Pulse Speed Info
  • The counters measure every “edge” not just rising – so every change of state of the Gray code
  • Pulses/Sec and pulse width are essentially the same thing (one is the inverse of the other)
  • Recommended Max Timer Interval is half the pulse width (ie Nyquist – you need twice the sampling rate of your signal)
  • Note that this whole section is averaged over the whole current “counter” period – hit reset counters to start counting again
• Azimuth Sensor Parameter
  • If Gray Code Mode is ON then this section uses the Gray code output from both sensors to calculate the parameters.
    • If bad Gray code was received this mode is automatically disabled
  • The Last Rotation section counts the pulses of both sensors over a full rotation (home sensor trigger to home sensor trigger)
    • Both sensors should read the SAME count (or within 1) – if not you’ve lost some steps…
  • Dome Diameter is the important calculation and is the data you need to enter into the LesvesDome configuration dialog.
  • Wheel Diameter and Number of Holes can be changed to match your setup.  Note these numbers are completely arbitrary and as long as you enter these two as well as the calculated dome diameter into the LesveDome settings, you should have a very accurate configuration
    • Note that this could be off if you have a very inaccurate home sensor – but I’ve tested this with the “default” reed switch configuration (possibly one of the less accurate methods) and it seems to be very accurate
  • Rotation Speed is in there for pure interest sake – it assumes you didn’t stop the dome during the rotation
  • Dome circumference is included for interest
• The log panel shows the log of the sensor readings in the following format
  • <time in seconds>,<Sensor 1 state>,<Sensor 1 count>,<Sensor 2 State>,<Sensor 2 Count>,<Home Sensor State>,<Home Sensor Count>
  • I included this in case anyone wanted to plot their own graph, eg in excel or something
• Main Graph Panel
  • Top trace is Gray Code visualiser – should be a nice “staircase” up or down depending on rotation direction
  • Blue and yellow traces are the output of the two sensors – should be nice evenly overlapping pulses
  • Red line is home sensor
  • I’m sure someone will notice this so I’ll mention it here…
    • Q: Why is the “staircase” not completely even on the screenshot
    • A: Firstly, this wasn’t variations in my dome speed, I actually used a microcontroller (Arduino) to simulate a perfect Gray code signal at a speed I could control.  If you look carefully you will note that the speed I’m sending pulses is close to exactly twice the sampling interval.  This is only just sampled well enough so that we get all the data – if I had adjusted the speed even slightly faster, would have risked missing a pulse (which would show up as a missing stair step).  This is why it’s important to look at your interval timer.
    • Also of interest, I pushed the performance of my (admittedly very non-optimised) code and my test board (a non-N variant – the N’s are in the obs) to see how far below 20msec is practical – whilst the code still worked fine if I pushed data in at a pulse width of 30ms or faster (15msec interval) I started to see missing steps.
    • If anyone is crazy enough to want to build a microcontroller “fake dome” then I’ll happily share the Arduino code and layout…
• Connect button is obvious and the “sk5/6” refer to the address jumpers on the board
• Timer Interval allows you to change the sampling interval (the software “polls” the board for the status of the inputs) – use this to see what happens if you have too high a number here – your “stairs” go crazy!
• Rotate CW and CCW should (if you have a standard setup) allow you to rotate your dome – press the button a second time to stop
• K8055 tester is all the tools Velleman provide in their “k8055Demo” program (and on their SDK samples).  I’ve built this in a way that is compatible with this page – ie if you start rotation with the “rotate” button, you can stop it by unchecking the output 1 checkbox