Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_imaging_challenge_banner_solar_25_winners.thumb.jpg.fe4e711c64054f3c9486c752d0bcd6f2.jpg

pmlogg

Wireless connection to Velleman K8055/VM110

Recommended Posts

1 hour ago, Gina said:

It's many years since I used one of those Velleman boards.  Nowadays I use the Raspberry Pi to which I add my own interfaces.

Any of the recently introduced micro computers is the way to go. Unfortunately programing is now beyond me, I dabbled with Fortran in the early 80's and that's it. CNC programming, and hand written in the early days, was my fortay.

Steve

Share this post


Link to post
Share on other sites

I've programmed in Fortran too and several other languages.  Mostly I use C++ these days with a touch of Python (though it's been a while since I used Python).

Share this post


Link to post
Share on other sites

Hmm,

Programming is definitely NOT my thing. I started on punched cards using Algol 60 then Basic over a teletype. Entered the micro age with a Nascom1, Z80 processor, programmed in machine code. There wasn't enough memory for an assembler. Then BBC Basic, a dash of 80286 and 80386 assembler and Visual Basic until it went modern after VB3.

I still can't do 'joined up' programming, all that object oriented stuff. I like a nice procedure or two and I do enjoy working with these simple processors like the Amtel chips in the Nano boards. It's more satisfying for me to have a direct connection to the hardware rather than layer upon layer of abstraction.

So, crunch day tomorrow for Magic Wire. Boards built and the basic two-way radio is working. Magic Wire firmware Mk. 1 written for both boards and a proper try out tomorrow. I will have to find a way of spoofing the various inputs and outputs - mainly just a matter of being able to connect / disconnect  the inputs to the various voltage rails. I have also put in some additional code to allow me to follow what's happening over a serial link to a terminal program.

Regards, Hugh

Share this post


Link to post
Share on other sites

Hi Steve,

Update time again.

I have made one more fairly minor amendment to the hardware. I have added a red LED to each strip board as shown on the revised drawings in the Rev 0.1 instructions attached. This LED is a diagnostic LED that will give a basic indication of any faults detected by blinking in a pre-set pattern.  

I thought this would be helpful as it is very difficult to work out what has gone wrong without some form of feedback.

I actually used a couple of LEDs with built in resistors, suitable for connecting directly to an Arduino pin and I have added details of these to the updated Parts list. However, a plain LED with a suitable series resistor, say between 500 and 1000 ohms would work just as well. The resistor would be used in place of the wire link between the LED cathode and ground.

The Mark 1 code for the two modules is now written.  Copies of the files for each module are attached. This is still early days stuff and will evolve quite a bit in the next few weeks.

I had a lot of fun initially as I just couldn't get it to work at all - I tried everything I could think of but - nada! As soon as I loaded the code into either module, it just went dumb and flashed it's little red LED at me. Finally I did some serious debugging, adding one line of code at a a time until I found the problem. It turns out that the breakout boards from Embedded Coolness have a fault! The Nano reset pin is connected to pin A0 and it shouldn't be! Naturally, the Gods of software had insisted that my 'helpful' diagnostic LED was connected to pin A0, so that when I initialised the pin, setting it low so the LED didn't light, that pulled the reset pin low as well. The Nano resets, starts loading the software again, gets to the bit where it sets pin A0 low, resets the Nano ...................................................

Anyway, what doesn't kill you makes you stronger . I changed the Nano pin used for the LED and the breakout boards work just fine.

As I mentioned before, I don't have a spare Velleman board so I am a bit limited in final testing. However, I have bought some cheap 12 volt DPDT relays from RS and a little 12 volt motor, so I am going to build a test rig to simulate the shutter operation, complete with limit switches. That will help a lot with testing.

I am also plugging away at writing the How To document. It is far from finished but I will eventually get there.

 Regards, Hugh

 

LESVEDOME DOME CONTROL HARDWARE.docx MagicWireSTATIC_0902a.ino MagicWireMOVING_0902a.ino

Share this post


Link to post
Share on other sites

Hi Hugh, 

Thanks for all the work you have put in so far. BTW software wasn't invented, it came out of Pandora's box and manifested itself into many guises. Luckily I have a spare Velleman board and I have been testing my circuit via Levesdome & SGPro. Which has proved successful.

1338495898_ShutterCircuit.thumb.jpg.ce4ec12b31e9d20d891060bc5126c139.jpg

I have lots of LED's with 47k resistors installed, so that's not a problem, just waiting for the breakout boards from Embedded Coolness to arrive.

I have found the full shutter circuit diagram I will use on my Dome. Obviously your wireless design will separate the circuit between the Velleman board and the relays/motor and 12v battery.

Shutter control circuit.pdf

Steve

Share this post


Link to post
Share on other sites

Hi Steve,

Thanks for sending the schematic. I will use this circuit for my mock-up. Looks like you should be able to test everything when you have the modules built. The delay in getting the boards from the US might be my fault - I notified them of the problem I had found, maybe they are getting corrected boards made. More likely, it's just good old ParcelFarce.

One thing to note is that if you want to use limit switches with the MagicWire system, you need to use SPDT switches. The common pole of each switch is connected to the 12 volt rail, the motor drive relay coil is connected to the NC terminal and the MW Moving board is connected to the NO contact. Then, when the switches are activated by the shutter, the previously floating contact gets connected to the 12 volt rail and this is the signal the MW board uses. I will sort out the actual wiring when I build my mock-up shutter drive. The switches I used were from RS, part number 682-2184. They are only rated for 3 amps, so they need to switch the motor via a relay, not directly.

Regards, Hugh

Share this post


Link to post
Share on other sites

Thanks for update, Hugh. I'll order the additional parts. Also, I received part of my Embedded Coolness order. It has been stated as 1 of 2 packages and funnily, it's been sent from Australia.

Steve

Share this post


Link to post
Share on other sites

I'm doing something similar. For years I've had a wireless dome link to an i2c controller which talked to the dome compass, but the controller itself seems unreliable. (It might be my code but not that I can see...). In the middle of a session it will just stop talking. Not what I need. 

So I have moved to using the Arduino toolkit driving Wi-Fi-enabled esp8266 devices. I talk to these over a REST api , which just means they host a simple web server and respond with JSON. 

I have a filter wheel done and the base unit for a revamped dome controller. The shutter unit that revolves with the dome is also complete but I am having trouble finding it in DNS from the base unit. At the moment. Once that is done, my shutter control will be in place. 

I too have a hygreon sensor lurking in the corners for rain detection, but the plan would be to create an ascom safety driver which monitors the environment as reported to the local Mqtt server which all the sensors pump their data to. In esp land it's very cheap to Wi-Fi enable these sensors to report centrally.

That will include weather, temp, dew, Aurora etc...

HTh.

 

Share this post


Link to post
Share on other sites

Hi SkyBadger,

You are doing proper, joined-up programming! Way above my pay grade I'm afraid but it does sound very interesting. I would love to get more details on your proposed ASCOM safety driver as that's one of the missing links in my observatory set-up.

My approach to protecting the equipment in the observatory has been to have all the safety inputs and control built in to my homebrew Arduino based controller. It works well and it covers various ways that things might come to harm. The stuff includes

Inhibitor switches fitted to the dome clamps (to block attempting rotation when the dome is clamped).

Detection of rotation motor jamming and automatic shut down .

2 off Hydreon sensors, one set for rain and one for heavy dew.

Aurora cloud sensor.

I also found it very helpful to have  the ability to  override the various safety detectors to allow basic fiddling, setting up in daylight, etc. This is all done through a programme called MegunoLinkPro that is a sort of poor man's visual basic. I have a GUI for my controller that allows me to configure it without needing to reflash the firmware. 

As I said, all this works and it is very pleasing to see the shutter close on the first drop of rain. The big lack for me is any way to interface my system with SGP so that there is a chance of pausing, then resuming a sequence. Hence my interest in an ASCOM safety driver.

Regards, Hugh

Share this post


Link to post
Share on other sites

Hi Steve,

Another Magic Wire Update.

I have finished designing the schematic for the relays as below. I have also attached it as a PDF file.

This is very much a Mk. One design and as yet untested. It took a lot longer than I expected to get a design that works - on paper anyway. This was due to the need to deal with keeping the states of the Fully Closed and Fully Open limit switches as reported back to the MW board valid under all possible conditions.

My next step is to do a hardware build of the schematic. I have some dinky little PCB mount relays so it will be a fairly simple strip board build. Then assuming testing goes OK, I will build a shutter mock-up in hardware using a small 12 volt motor and a couple of limit switches.

I have had a break from writing the MW firmware but there isn't much left to do. My TTD list is 

THINGS TO DO
============
Option handling - Finished in Static Module. Moving module in progress

Write Shutter Close procedure. Moving module.

Write Battery Voltage stuff. Moving module.

Write Comms Check stuff. Moving module.

How are you getting on with making the modules? Please do let me know if you hit any snags as that would be very good feedback.

Regards, Hugh

 

 

 

 

 

image.png

MW_ShutterSchematic_Rev01.pdf

Share this post


Link to post
Share on other sites

Hi Hugh,

Thanks for the update. I've now received all the components to build the project. Hopefully should start building Friday.

Kind regards

Steve

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.