skybadger

Sure, but it's up to you to find resistor values that are equally spaced from a standard value sec. As lo g as you can distinguish between them it doesn't matter.

I had to search for it but it is downloadable here https://pubs.er.usgs.gov/publication/sim3316 hth.

You only need one adc for reading the voltages acRoss the bearing resistor network according to one supplier. (But not usi g the Circuit above). The adc doesn't have to be the native one either, I use one on the i2c bus for that and the bme device. The anemometer only needs one Reed or hall or other sensor which means one pin, but if that is not the way you want to arrange things there are other ways, two digital pins for an encoder or optoswitch for example.

The Reed switches only need a single resistor to create a bridge if you are reusing an existing setup. Otherwise you will need 9, one for each octet and 1 for the bridge. The adc should not be configured for pull-ups or downs, those options won't be available for an input configured as an adc.

Once you have the boot loaderi n there, you can update over the air using the updater library.

That will work fine under Linux, using the Linux Arduino ode or the esp tools which are python.... setup the board library and you are off running. That is a -12f version.

I get 20m out of mine, across the garden from a wall plug AP.

Jpl published a whole moon map that's about 4 foot to a side. It's freely downloadable and at some point I'll print me a copy for the wall.

For me, the esp8266-01 is tiny which is the benefit over the -12 or -32. I have many of each to hand...

Links to ultrasonics: http://embedded-lab.com/blog/making-an-ultrasonic-anemometer/ https://hackaday.com/2013/08/21/ultrasonic-anemometer-for-an-absurdly-accurate-weather-station/ https://www.dl1glh.de/ultrasonic-anemometer.html The hardest part for me seems to be the resonant tuned driving circuit but I expect there are examples of them on the net too.

Link to my github for ESP8266 code : https://github.com/skybadger The maplins weather centre uses this scheme: https://www.argentdata.com/catalog/product_info.php?products_id=145 If I wanted high resolution wind diiretion sensing I'd probably go for a s cheap HP 400ppr HEDS encoder. Actual resolution is 1200 so loads of data but you might suffer from missed edges if it rotates fast. THE ESP8266-01 has 4 io pins , of which 1 is TX out for debugging, Rx is used as GPIO and GPIO0/2 are used for i2c to the ADC and BME280. Which means if I want to count anemometer edges I need an extra pin, same too if I want to count water bucket closures. Which meant I went to the ESP8266-12. I am using the adafruit huzzah ESP for this and currently boxing it up to fit inside the old maplins enclosure, which is where the challenge lies, the coding and parts all worked on the bench....

That's the badger! but using the -12 version due to having more pins. My git pages have a bunch of Alpaca drivers on them that use the same general code pattern. The change is adapting for the sensors. I'd have thought you'd be up to building an ultrasonic sensor for speed and direction in one hit rather than remake the delicate propeller parts.

What you are doing is providing a star at infinity from the reference scope to use as a star for the scope under test. It's sound, but you need a 12" scope to feed a 12" scope. This is the same as using an optical flat to dual-pass test optics with a ronchi. You need the same large optics to feed the scope under test. A false star at the end of the garden or reflected back to you from the end of the garden is the more practical approach in absence of an optical lab and expensive flats.

Hi I am rehashing the guts of my old maplins weather station with an esp8266 for the wireless aspect , only needs 4 pins, 2 are i2c, 2 are edge detect for the wind speed and rain counter. The i2c provides temp, pressure, humidity, adc and even an Sqm if needed. The Adc is used to read the wind direction resistor encoding. Sadly it needs power but a solar panel might do for that. Total cost , about £30 in components.

I suspect cameras still have 1/4 whitworth for the threads, unc just happens to fit in spite of the different apex angle.

Right. Tracking that now. Ta.

Thanks for the update. While I understand the stocking issues there are as many problems pre-announcing too early that are only solved by good comms! Eagerly looking forward to this. Can you remind us of the website please to take part in development ?

Well his website says you can, but I have signed up twice and had no feedback...

HI Stuart I had to think what the autohome was then. Isnlt autohome only avaiable on the Synscan handset ? I stopped doing that a long time ago becuase I use a side-by side setup which turns home through 90 degrees and occasionally the mount would turn the scopes upside down in search of home. For the 12" RC I thought that was quite scary. cheers both Mike

Hi both. Encoders - not purposely turned off. Eqmod doesn't say eq8 when it connects, it still says eq6. Ken, I use whatever park position is suitable. If having to restart due to an issue, I use polar home, otherwise park in place or park at W and E presets has been perfectly fine until now. The only large systemic change I have made is to adopt Voyager as my end to end imaging platform but that is not involved in this. What sort of things have you seen ? Cheers Mike

Hi all I have an EQ8 mount controlled through CdC (latest release) and use POTH to sync with the dome. Over the last couple of weeks I've done something to cause a slewing error and I cant work out what it is and I'm pulling my hair out trying to fix it. Starting from a position where all the sync points are cleaned down, I can move the mount from home to a location using CdC to tell the scope where to go. I home in and hit 'sync'. i move to a second nearby location, home in and hit 'sync' . I go back to the first target and off the mount goes. Nowhere near. EQMOD is reporting being at the target location but the target location that CdC is claiming it is at, is not the location of the actual target . Here is a pic to illustrate CdC is saying that the scope is at the target - m5 but EQMOD is clearly saying that the actual location is nowhere near ...( something like 16:04/02:00 J2000) . I have tried checking: Cleaning down the EQMOD Sync re-setting home on the mount checking time, location agree between the mount and CdC checking the pc time is accurate -and its not a BST/GMT issue - its not consistently a BST hour between target and actual . I run the PC in GMT and have checked CdC is reporting the correct time The mount is permanently mounted on a fixed pier and hasn't had any knocks that I am aware of to upset the polar alignment and racking is good once homed in on a target. The only components in this system are EQMOD and CDC. POTH is a client of the same EQMOD Driver as CdC is . Any ideas gratefully received Cheers Mike

Should have said I use it with a quark.

I use a cheap diagonal for the purpose of not staring into the sun. With that I have a 26mm Meade plossl and a X.5 screw in reducer. I prefer the 26mm. The scope is a stellar St80 ed at f/5 or so. I couldn't tell the difference between using the diagonal and not using the diagonal from the image alone.

Stellavue St80

I put a 35nm filter in front of the filter and just got poor viewing (fuzzy details and lower contrast) so I took it off again. So, ultimately, no pre-filtering at all.....