Relays for Lesvedome

[hughgilhespie]

Hi Peter,

Good that you have been able to pinpoint the problem. As I said before, I have absolutely zero knowledge about Raspberry Pi's and their software. so I'm afraid I can't help. In my observatory I use a pair of XBee radios to pass the signals between the battery powered shutter drive, located in the rotating dome, and the main controller fixed to the non-rotating observatory wall.

Hopefully the VirtualHere support can get you going. If they can't there are other options I can think of but they are far from quick and easy. These would involve moving the VM110 board to a static part of the observatory with a wired USB connection to your computer. Then a homebrew radio board (Arduino + transmitter/receiver) would be connected to the VM110 digital inputs and outputs.  In the rotating part of the obsy, a very similar radio board would connect directly to the relay module inputs. This is all 'doable' but it's far from a quick fix.

Let us know how you get on with VirtualHere.

HTH

Regards, Hugh 

[symmetal]

Peter,

I would think a WiFi Remote Desktop solution would be a more reliable solution than the remote USB option as in the event of loss of WiFi link the remote computer carries on working. I don't know how the remote USB handles that problem. Even with a strong WiFi signal momentary signal dropouts would likely occur. You could try the compute stick and it may be better but still couldn't guarantee no dropouts. How VirtualHere copes with that situation is the main question.

Alan

[pmlogg]

Hugh and Alan

I've been in email conversation with VirtualHere. Due to the time difference to Sydney I won't expect to hear more until a few hours from now at the earliest.

I've asked about updates to the software, listed on their website and newer than my versions.  The newest for the client describes it as:  "Fixed - bug where ssl connection may jam if using wifi and wifi drops or goes out of range" and the newest for the Raspberry Pi end  as "fixed bug where an SSL connection may lock if wifi goes out of range or drops and wifi is used between client and server"

Not sure if they will resolve it but sound worth a try.

In remote desktop there would be two wifi links rather than one.  If the one to the mount dropped during a slew might that not potentially leave the mount moving?  I have limit switches programmed but there would still be risks to dewstrap cables etc. It's a lot less problematic if the dome kept going.  I've not wired in the 'dead man's' switch that is shown in some Lesvedome circuits.

Thanks

Peter

[pmlogg]

Hugh and Alan

VirtualHere has said they reckon the issue is the wifi saying:  "The reason is that the chip on the pi3 is not very good for wifi. You should try other boards if you can e. glike the GL-MT300Nv2 which has 2T2R and dual internal aerials." This a bit disappointing as they had suggested using the Pi. Anyway the GL-MT300N-V2 is not expensive, will fit into the same space on the mounting board and use the same power inputs and outputs.  At this point I have to put the project on pause for a bit due to family reasons - a restart in mid-July. I'll send an update then.

Thanks, Peter

 

 

[symmetal]

Peter,

Hope you manage to resolve it OK. The GL-MT300Nv2 looks like quite a useful little box and hopefully will give you more reliable WiFi. Good luck. See you in mid July. 

Alan

[pmlogg]

Alan and Hugh

Just a brief report as time is short.  The new device arrived today - I'd forgotten we have an unplanned Amazon Prime trial.  It was very quick to set up with the VirtualHere software and then connected to the main computer just as easily.

Testing with K8055_dome worked with none of the glitches experienced with the Raspberry Pi.  Similarly I got repeated CW and CCW movement in Lesvedome User Interface.  The only glitches I did get was when I hand moved the encoder wheel - then I got a stall.  So when I do return to the project in July my first step will be to go to the older version of Lesvedome.

I was considering the best way to mount the device either with or without its case within the space left by the now-removed Pi but it does not have standoff holes placed for that purpose.  It is however so small and in its own case that I may just use it outside the enclosure, directly attached to the powerbank and just connecting to the VM110 by  usb in and out of the socket on the case. Not really much extra hassle of an evening.

As I wrote before I'll post again as soon as I've made further progress.

Thanks, Peter

[symmetal]

Peter,

The new unit sounds promising. Hope you get it to work without any problems.

Alan

[pmlogg]

As an update, back from holiday I fitted the enclosure for the VM110 and relays and did a test of the new encoder box with spring tensioner.  Unfortunately the test did not go well but at least I think I know why.

The encoder wheel is at the bottom of the box when it is fitted and although I have two bearings what I didn't have was anything to prevent tension or compression along the shaft of the encoder wheel passing those forces onto the encoder. I suspect that the combination of some residual misalignment plus push or pull on the encoder shaft caused it to seize. 

I've had a look at the design and plan to add a bracket with a bearing for the lower end of the encoder shaft to eliminate those axial forces plus an extra pillow bearing within the box.  Just waiting now for delivery of a replacement EM14 encoder and more aluminium angle plate; the bearings have arrived.

The older version of Lesvedome is installed and working fine with the set-up and I now have my permanent license.  I also did some tidying up of the wiring, reducing the length of the cables - so its the mechanicals rather than the electrics or electronics now holding up the show!

I'll post a picture of the revised box once completed.

Peter

 

 

[symmetal]

Hi Peter,

Hope you enjoyed your holiday.  Bad luck with the encoder. They are rather delicate.

Alan

[hughgilhespie]

Hi Peter,

The encoders are a bit delicate!

I have attached a photo of how I mounted my encoder. The actual encoder is in the diecast box at the bottom - I was worried about it picking up interference from the motor close to it. As you can see, I used a pillow block bearing for the shaft that connects the encoder to the pinion. The bearing I chose has grub screws that lock the shaft into the bearing. That stops any up and down movement being transmitted down to the encoder. Then the actual encoder shaft is joined to the drive shaft using a flexible coupling. That allows for a small amount of sideways misalignment. It's not shown in the picture but the whole encoder assembly is mounted on a hinge so that it can move in an arc and the spring arrangement keeps the drive pinion pressed into the drive belt. The side cheeks were an afterthought as there was too much sideways play in the hinge so they are there to prevent that.

It looks a bit complicated but actually it is only made from aluminium bar, plate and angle.

Hope this helps.

Regards, Hugh

[pmlogg]

Hugh

Thanks for that image and the explanation.  Yours is a much beefier encoder wheel shaft than mine (6mm).  I had a look to see if there were bearings like yours available for 6mm but the smallest size was 8mm - however an option could be an 8mm to 6mm bore adapter - which Huco make.   There looks to be just enough space in my enclosure for one of the 8mm pillow bearings so I'll give that some serious consideration.

In the meantime I've fitted the board with the VM110, relays and UBEC into the enclosure on the dome wall and connected up the motor and battery.  The test with Lesvedome user interface worked fine, wirelessly from the indoor computer, as it had done when inside with the model motor.  I even managed to have CE /CCW correct.  So the encoder set up looks as if it maybe the last major hurdle.

The replacement encoder should arrive tomorrow but with family visiting this weekend I may not be able to make very much progress.

Thanks

Peter

[pmlogg]

The revised encoder enclosure with additional shaft bearing, plus extra effort on achieving alignment encoder shaft to encoder wheel shaft has been working.  I had to adjust spring pressure to avoid the wheel coming off the dome wall in one part of it. So angle measurement from the encoder and slaving via Levesdome + POTH seems to be working.  My measurement of dome diameter was only out by 2.1mm due to luck I'm sure.

However for some reason the Hall Effect Switch wasn't reacting when passing the home position magnet (which was within range, and correctly oriented).

My initial thought was that I might have a lose wire on one of the Switch's connections or that the diode in the circuit between the VM110 Digital Input 2 and the Switch's output might be blown.  The diode checked out as did the wiring continuity checks.  So all I've been able to do is tighten up the connections and will try again.  If that fails not quite sure what to check next as everything else was working in the dome and during the indoor bench tests the Hall Effect switch was registering fine.

[pmlogg]

The Hall Sensor, tested with a spare magnet, registered under the K8055 programme so the encoder box was refitted, Lesvedome run and it works with the resetting to the Home Setting taking place when the Hall Effect Switch rotates past the fixed magnet.  There was no time tonight to check a slaved slew nor that the other parameters I entered into Lesvedome are accurate enough for consistent alignment.  That for another night. 

Here are pictures of the revised encoder enclosure internals and externals. I used a longer shaft which goes through the new external bracket. The space for the wheel is such that the shaft bearings above and below act as a proxy set screw, removing all but a fraction of a mm up and down motion.   

Also shown is the complete system other than the original Pulsar/Rigel keyfob and receiver that form the 'manual' system.  The switches on top of the original Pulsar/Rigel unit are 3-way.  Pushing outwards to the dome connects the new system to the battery and rotation motor.  The middle position is off and the inwards positions connect the original Rigel circuit board etc.  The wall mounted box contains the Velleman VM110, the relay board, UBEC 12V to 5V regulator and the connections DB9, USB and XLR for 12V from the battery and to the rotation motor. On top of the Pulsar/Rigel unit is the Powerbank and the GL.iNet GL-MT300N-V2 Mini Router.  They are brought indoors for charging.  Protruding from the bottom right of the Pulsar/Rigel unit is the Encoder enclosure with tensioning spring, and DB9 connecting cable. Just to the left of it, on the dome wall is the fixed magnet.

It remains to be seen if the wifi link can run without dropouts but so far the signs are promising.

[symmetal]

Coming along nicely there Peter. Glad you got the Hall effect sensor working okay after repositioning it.  What's the skewed bearing doing below the flexible coupler?

Alan

[pmlogg]

Alan

Thanks for that, and again for your help.

The pillow bearing is at an angle as I slightly mis-calculated when drilling the hole for the shaft through the casing. The Igus pillow bearing insert is a ball so the angle I've mounted it at makes no difference to its operation. It's there to support the encoder wheel shaft rather than exposing the encoder itself to radial forces. The two shaft bearings are also from Igus and of similar format, i.e. balls within a housing.  The speeds of rotation are well within the tolerances of the bearings which do not need lubrication and won't rust.

If I'd not managed to get the alignment sorted I had thought to add a second pillow bearing in that space but it would have required moving the encoder bracket backwards - and space is limited for that, or start again with a new enclosure but that would have been a lot of extra work.  Luckily using the adjustment that was there with more care than the first time round did the trick as far as smooth rotation was required.  I should have done more from the start to restrict axial motion of the encoder wheel shaft as I did wonder about it earlier in the process.

It looks a bit Heath Robinson with the attached brackets for the Hall Effect Switch and the 2nd shaft bearing but it seems to work.  In terms of cosmetic appearance I'm happier with the enclosure box for the relays and VM110.  The three cable entry points have worked out pretty well. 

I think there is probably enough room in the enclosure for more relays if I do, in the future, want to try shutter automation.  However, with the need for things to be switched on, uncovered etc. and my fear of depending on the system reacting quickly enough to close in the case of rain a powered, automated shutter is a low priority.

My next stage will be to verify that the data I put into Lesvedome in respect of the mount geometry is accurate enough to maintain alignment shutter to telescope.

Thanks

Peter

[symmetal]

12 hours ago, pmlogg said:

The pillow bearing is at an angle as I slightly mis-calculated when drilling the hole for the shaft through the casing. The Igus pillow bearing insert is a ball so the angle I've mounted it at makes no difference to its operation. It's there to support the encoder wheel shaft rather than exposing the encoder itself to radial forces. The two shaft bearings are also from Igus and of similar format, i.e. balls within a housing.  The speeds of rotation are well within the tolerances of the bearings which do not need lubrication and won't rust.

Ah! That explains it. Looked at their website. I imagine it's a PTFE type ball material. Good luck with the Lesvedome alignment. 

Alan

[pmlogg]

Hugh and Alan

Finally some clear sky tonight so I was able to give it a good test, not imaging but just slewing onto different targets.  I had to increase the GEM offset figure in POTH to get closer to the mid-point of the shutter but other than that the slaving seems to be working exactly as required.  It's such an improvement from having to hold down the button on the key fob while the dome slewed to a new target.

Also positive is that the VM110 and GL-MT300Nv2 seem to draw very little power so that the power bank re-charges very quickly.  On current performance I don't think that having those components powered by a battery is going to be an issue.  A cold winter night's imaging will be a better test though.  The Wifi link has been glitch-free too.

Thanks

Peter

[hughgilhespie]

Hi Peter,

Well Done!!

You must be really pleased. Astro imaging is never going to be easy but when the automation works it takes a lot of the hassle away  and leaves you free to concentrate on getting good results.

Speaking of automation, if you do decide to automate the shutter operation, I have a design for a radio link for the Lesvedome shutter control that in effect connects the shutter to the VM110 / K8055 via a length of magic wire. The details of the mark1 design are in the topic 'Wireless Connection to Velleman K8055/VM110' that you started in this forum. I am doing this with the help of another SGL member and between us we should have a working design fairly soon.

Once again, congratulations on a successful project.

Regards, Hugh

 

[symmetal]

Hi Peter,

As Hugh says, congratulations, you've done a good job there on getting it all working. Hope it remains problem free for your actual imaging sessions. 

Alan

[sloz1664]

Good job Peter, hope everything goes and stays well.

Steve

[pmlogg]

Many thanks for those good wishes.  I have been keeping an eye on shutter plan. 

The 2-part shutter on my dome does complicate matters, requiring another motor and extra limit switches.  My thinking has been that having my VM110 already moving with the dome, and being linked by wifi to the controlling computer, should make hard wiring to the VM110 possible.  Perversely linking the cloud and rain sensors would be made harder. 

Thanks

Peter