Jump to content

SkySurveyBanner.jpg.21855908fce40597655603b6c9af720d.jpg

Why are new mounts still coming with serial cables?


Alaness

Recommended Posts

Why on earth does an application need to know the scope position five times a second!

That is why the driver does some throttling of serial commands by, for example, only checking the Ra and Dec twice a second. The trick is to allow time critical things, such as guide commands, through.

If you have issues using the Celestron driver with that Christmas tree then let the developer know (that's me) I may be able to help.

I'm in the process of doing a rewrite in C# instead of VB6 so it's quite a good time. What does emerge is that it's worth continuing with the hub capability.

Chris

Link to comment
Share on other sites

  • Replies 46
  • Created
  • Last Reply

Ah, a developer! Me too! Well, the issues I had probably has nothing to do with your efforts, but it just doesn't sing with the GM-series and I guess nobody checked.

My driver is currently in the in-process stage but I am going to move it out-of-process soon. I think the main problem may well be MaximDL. I did some tests with thread spawning in my driver and it worked fine with my model maker, Cartes and FocusMax. Maxim, on the other hand, went haywire when I created a new thread in its process space.

My take is that the only way to do a proper driver that works with Maxim is to go out of process.

Now, this leads me to think that doing optimizations just doesn't work with Maxim. That may well be the source of the problems when hooking a 10Micron product doing LX emulation to Maxim. Also, making the 10Micron products truly LX comaptible or the LX driver 10Micron compatible is not the way to go. The LX driver should work with LX mounts and the 10Micron driver should be good with 10Micron mounts. In fact, I have made a number of tweaks that has nothing to do with LX and the mount still have to be in LX mode.

As for five times per second, well, it should be able to I think. I, for one, hate it when the graphical representation of what is happening moves in giant leaps instead of smoth movements. And you can't interpolate everything. Among the best code I have seen in this respect is Stellarium. Smoth movements and not overly "polly" to the mount. Good thinking. Still, asking for a position five times a second in 2013 doesn't sound like over doing in it my view.

Yes, I agree about the hub capability, which is the main reason I am moving out of process. Should we share notes, perhaps? I do work in VB2010 but know c#...

/per

Link to comment
Share on other sites

Ah, a developer! Me too! Well, the issues I had probably has nothing to do with your efforts, but it just doesn't sing with the GM-series and I guess nobody checked.

Is this something to do with the Celestron driver? Not sure how that's involved with a camera.

My driver is currently in the in-process stage but I am going to move it out-of-process soon. I think the main problem may well be MaximDL. I did some tests with thread spawning in my driver and it worked fine with my model maker, Cartes and FocusMax. Maxim, on the other hand, went haywire when I created a new thread in its process space.

My take is that the only way to do a proper driver that works with Maxim is to go out of process.

You could be right, out of process should be less invasive. Not sure what driver you are doing. Celestron scopes? A camera?

Now, this leads me to think that doing optimizations just doesn't work with Maxim. That may well be the source of the problems when hooking a 10Micron product doing LX emulation to Maxim. Also, making the 10Micron products truly LX comaptible or the LX driver 10Micron compatible is not the way to go. The LX driver should work with LX mounts and the 10Micron driver should be good with 10Micron mounts. In fact, I have made a number of tweaks that has nothing to do with LX and the mount still have to be in LX mode.

Not sure what you mean, LX? Is this something that's using the Meade LX protocol?

As for five times per second, well, it should be able to I think. I, for one, hate it when the graphical representation of what is happening moves in giant leaps instead of smoth movements. And you can't interpolate everything. Among the best code I have seen in this respect is Stellarium. Smoth movements and not overly "polly" to the mount. Good thinking. Still, asking for a position five times a second in 2013 doesn't sound like over doing in it my view.

Bear in mind that at the other end of the cable is a poor unfortunate microcontroller running at 20 MHz that's controlling a mount as well as responding to messages from the serial port. As far as that's concerned it's about 10 years ago.

Chris

Link to comment
Share on other sites

Why on earth does an application need to know the scope position five times a second!

...

May be it's needed to run a high resolution encoder like a TDM or using an active optics guider.

It's interesting how this thread gradually turned into a discussion between engineers on the merit of RS232. :D Something you will never see in a photography or birding forum

PS. RS232 is still common in the marine industry although many device can be configured for both RS232/422/485. The last two sonar I worked with used RS232 and I'm really really grateful for that.

Link to comment
Share on other sites

Yikes! I mixed up the Celestron and the Meade LX. My bad! Sorry about that. Thing is, 10Micron is LX compatible and they ship it with the generally available LX 200 driver as one alternative way of talking to the mount.

The rest, I guess we're in agreement ;)

/per

Link to comment
Share on other sites

Turning that around - are there any drawbacks for ethernet? (Apart from the flimsy connectors you'd usually see - that can be fixed though. I use XLR for everything - power and USB and, well, whatever I need to hook up.)

/Jesper

Link to comment
Share on other sites

Turning that around - are there any drawbacks for ethernet? (Apart from the flimsy connectors you'd usually see - that can be fixed though. I use XLR for everything - power and USB and, well, whatever I need to hook up.)

/Jesper

Just read some reviews for Vixen Starbook. For a start, it wouldn't connect without a router. Then, no one else uses ethernet in amateur astronomy so you get a lot of compatibility issues.

Although, to be honest, a lot of Starbook's problem is related to its closed proprietary software, and not just the use of Ethernet.

Link to comment
Share on other sites

Just read some reviews for Vixen Starbook. For a start, it wouldn't connect without a router. Then, no one else uses ethernet in amateur astronomy so you get a lot of compatibility issues.

Although, to be honest, a lot of Starbook's problem is related to its closed proprietary software, and not just the use of Ethernet.

Well, quite. Those aren't problems with ethernet per se. Those are problems with software and/or documentation. It's not that hard to find RS232 kit that won't operate when the other end of the connection is using TTL signalling levels. That's hardly the fault of RS232 though.

James

Link to comment
Share on other sites

The big disadvantage with Ethernet is that it makes much more demands on the software and hardware. An Ethernet stack is a significant amount of code and/or requires a special Ethernet IC and the Ethernet connector requires special connectors with transformers in them. This is all insignificant in the context of a PC but not so for something such as a filter wheel or focuser that only needs a small microcontroller to do the work.

Chris

Link to comment
Share on other sites

Serial......

Cheap and easy to implement .....common chipsets, well understood, cheap, everyone can agree on pin oits, connectors etc.

Robust...reliable, simple, easy to make cables ( try making a USB cable sometime ) or ethernet come to that without soending cash on a crimper tool.

Solid standards where everyone knows what needs ro be done, no confusion or diverging standards like you get with USB at times, ethernet connection ? What type ? 10/100/1000/10000, MAU, RJ45, STP, UTP, BNC etc etc. Ethernet has changed a bit and is still changing.

Longevity of support.....look how many versions of Ethernet have been around since 1986

, imagine where you would be now if you were lumbered with a token ring connection or an Ethernet MAU connector or some other world changing connector that never took off or got canned.

Flexible...can be run big distances, can be line driven to massive distances if needs be. If monster distance required can be carried as a serial tunnel in almost any route across IP.

Convertability......want to xonvert it to USB, Ethernet, Firewire etc...no probs there is a box oit there that can do it.

Out the loop....easy for third party developers to work with.

Long support cycle......serial has been around forever. You cant say that about a lot of PC/Mac technologies. Telescope mounts can have a long life. The EQ6 has been around over 10 years...and it could be around for another 10. How many whizz bang comms producits can come into existence and disappear again in that time.

Low power consumption and hardy enough to work in all weathers. Try gettng Ethernet to work reliably out on a hillside when its damp. The chipsets will eat more power and I have seen induced voltage into even short Ethernet patch cords caused by a radar near an airfield that completely messed up Ethernet where serial would still run. Its rugged is serial.

Lordy...just buy a serial card for your PC for a whopping £10 and get over it. You dont exactly need high speed data transmission to a telescope mount. Its not like its having to download monster data is it ? When was the last time you needed to send much to a mount ? Go left a bit aint much data you know :)

Link to comment
Share on other sites

I work on Commercial Aircraft (Boeing 737 & Airbus A320) and we still use Floppy disks to update the computers, 4 hours of disk swapping (20mins per disk) just to update an Autopilot to new firmware!

We also still use RS232 and others.

Link to comment
Share on other sites

Jeez, this turned into a frenzy ;)

First of all, the discussion started with mounts, so let's stick to that application.

Just for the record, regardless of how widely used it is, it is a technology with limitations. RS232 debuted in 1962 and was revised to the current level in 1969 (RS232C). By specification it can do 20 kbps at a distance of up to 20 ft.

Now, can we run RS232C at longer distances? Yes, sure, but we are then outside of specification. You can, as astrobaby points out, line drive it and thus deviate from the standard.

RS232C lacks any form of power supply capability. Yes, you can steal a few mA from the handshake lines, but you cannot power anything real.

RS232C is single ended with voltage levels of -25V to +25V (unloaded) on the driver side and -15V to +15V on the driver side (loaded) and the receiver side. Raising the voltage to such levels is done to combat noise. Receiver sensitivity is -3V and +3V.

There is no specification for cable impedance but there is one for max slew rate (30V/uS).

So, what are the actual problems, then?

Single ended means absolutely no resistance against noise. I have taken down RS232 equipment from locations because it bombs out every time someone turns the flouresant tube office lighting on.

Single ended means any error in grounding of equipment results in ground being carried by the RS232 cable. Fine if you have thick cables and a 25-pin connector, not so fine if you have 9-pin and haven't soldered a ground wire on the connector casing. They did away with the protective ground in the 9-pin version... I have seen computers and other equipment damaged because of this. Signal gets distorted and your RS232 cable gets to be responsible for the protective grounding.

There is no specification for any form of multidrop.

OK, now how much traffic is there going on with the mount? More than most people think! I had to dig into this kind of stuff because I needed to write a full ASCOM driver for 10Micron mounts. For your pleasure I have connected four clients to an ASCOM telescope simulator and looked at the traffic. This setup is not a fair comparison because the telescope simulator has virtually zero latency in answering calls and virtually zero communication time between the mount and the computer.

Here's four clients' (two charting applications, one imaging aplication and my model maker) screaming at the mount (all clients are idle and only putting the scope symbol on the chart) http://filer.frejval...ntcomm.swf.html

In order to accomadate the bytes going back and forth, a mount with LX emulation (or AP) would need a minimum transfer rate of 19200 bps.

Every time a mount introduces any latency in the direct response (acknowledgement or actual data), the client application will be non-responsive. This is an inherent design in the out-of-process ASCOM specs. Some clients are better than others, and if you feel that Cartes du Ciel is a bit on the slow side in terms of user interface response, this is why. The driver "steals" cpu time from the client's processing thread and uses it to wait for a mount that needs at least 100ms just to get a simple command done. If you use EQMOD you're better off as it is out of process (a separate application taking on the burden).

I will not even mention USB as an alternative as it suffers from so many reliability problems, both electrical and mechanical.

Now, how many of you have a laptop with a serial port? Most modern ones don't have it. So, you end up running USB to serial converters ;) In that scenario, I would prefer USB all the way to the mount, but let's stick to Ethernet vs RS232C.

One of the most common mounts, the NEQ6, uses a naked form of serial communication that uses +5/0V (TTL logic levels). This has NO noise resistance and needs a level converter (EQDIR). Put that as close to the mount as possible.

Let's talk about Ethernet. It is a differential transfer method with a maximum cable length of 100m. The cables are well defined in terms of impedance, very cheap and being differential it is very difficult to disturb. Besides, it has nifty features such as error detection and re-transmit. With RS232C you get what you get, no matter how wrong, and can only protect yourself agains single bit errors (parity, which most mounts don't use).

Ethernet can power devices at levels up to 25W. If you use a loophole in the POE (Power over Ethernet) standard you can get 50W. And that's using a 100m cable! That could drive a good portion of the mounts out there.

The connectors, although fairly easy to break if you plug/unplug all the time, are dirt cheap and easy to replace. Ready made cables cost very little. If the little clip locking the connector in place is not broken the connector is very reliable.

Ethernet is a base technology at the lowest level in the OSI chain. As such, it needs upper layer components, which means IP and TCP.

IP can be transported reliably around the world with very little latency. TCP is totally error corrected and defined as "a reliable stream", which means that whatever is poured into one end runs out at the other end in the same order with no missing bytes, even though several underlaying packets took different routes around the world.

Is this complicated for the mount producer? Nope! A standard microcontroller, say a PIC or a Rabbit, is available with Ethernet hardware and a vendor supplied software stack that is very easy to use. I have yet to see a family of microcontrollers worth the name that lacks Ethernet support.

This turned into a rather complicated mess of statements, but I really want to say that RS232C has its merits, but in comparison to Ethernet as mount transport it is dead in the water. If we adhere to specs it is simply unusable for anything past one client. Some might say that you run five clients with no problems, but I beleive you actually do have problems with a setup like that.

I dream of a day when mounts always have direct Ethernet/IP/TCP as an option! Two of my three mounts do and I am very glad for that!

/per

Link to comment
Share on other sites

Sorry Per disnt mean to sound aggressive on my post up there, was supposed to be ironic but pethaps it didnt come over. Any apologies for any offence...but I think people look at this from the wrong direction ie nice to have instead of whats reasonable.

My background is comms and I go back far enough to SECMAT and Telex and an age when a 9.6 kbps modem was close on £3,000 and you needed a leased line to run it on !!!!

Worked for IBM, Honeywell, Cisco and a fair few thers in my time in various functions. Now if I were speccing it from inside one of these organisations I woud a e gone for fibre and Ethernet probably at 100BaseFX spec BUT thats cos. am comms backgrounded and would have gone for speed, ease of chipset availability in my own market place and also because I would want the customer to spend more money with me :) soz but thats commerce. I might have downspecced it to 100BaseT to be nice.

But back in 2001 when these mojnts started shipping a lot of users would have had no 100 Base Card. 100Base ethernet was very slow to take off you know. i worked for a cpmpany bonded to Intel at the time and we had a lot of grief becaue Intel kept stressing about how slow the takeup was.

Now all of that is because I am a comms person and used to working in comms companies. Where I work now we have PCs which are nine years od and we only just moved to Windows 2000........thats the world outside the world of IT and soecialist comms companies. The network is 10Base only. Thats what bits of the world are like and I am talking UK here not Ulan Bator.

Now if you were a manufacturer in 2001 , or even now come to that, and you had to put a comms interface onto something that was available almost anywhere in the world, well unrstood almost anwhere, as technically independent as possible so you can guarantee not having to redevelop later on and leave older users stranded, has to be cheap, easy supply of parts but crucially available anywhere yo may want to sell the mount which might actually be in Latvia or Outer Mongolia and given that you are a company that is not a comms or network specialist, you are after all an astronomy company with limited resources to focus on interface issues then ou can probably do no better than serial.

Thats why it gets used a lot, its not its technical simplicity its the commercial realit as a company yo arent going to employ people just to build one small interface on a few products because you dontp have the techno expetience inside.

Theres other asons as well to do with product entrance to the market. You cant afford foul ups. Thats why Ford used an ancient engine in the Ford Ka. The whole car was so radical at the time Ford didnt fancy pushing their luck by introducing a radical car with a whole new motor so they played safe. Synta probably did the same when they bought the mount out. After all how many people would have had Ethernet in their house in 2000 ????.......i can tell you that back then I had a millenium party at my house and because I had a PC and internet most of the people at the party we amazed.....ohhh what can you use it for ? Was what I got asked all evening. Its easy to imagine the internet is ancient......in truth yes it can be traced back to the sixties but for most people its only been around for 12 years or so.

Thats how fast it has all moved. And thats probably at the heart of if...if yo had to bet on an interface with longevity today yo might bet on Ethernet but even now I would probably go serial unless the data throughput was massive just for the fact its available, cheap and wherever I take my product I know I can get it connected.

Link to comment
Share on other sites

Actually....rethinking it....be glad its serial, let your heart sing a song of joy because if ai were the product manager I would have developed a proprietary interface. i'd probably call it AIDA....Astronomy Interface Digital Access. It would use a proprietary connector to kill off any third party suppliers. Something cheap to make but impossible to copy. I'd probably build in some weakness so you had to keep replacing a cable, naturally people would moan but once locked in they would have no choice but to replace the cabe which would costs maybe £15 a go, enough so I can make exta cash for the company but not so much that users would seriously complain.

I'd want something complex for the interface, fibre perhaps to deter any home brew stuff. Of course I would make extras for which you would bleed cash for. An interface card so you can use an astronomy program, an adapter to convert my interface to something simple like serial, you would be made to pay for that.....big style. I might do my own astro program and make you pay for that as well. You coud cough up £150 for my program or £100 for an interface so you can use Stellarium. I would interface for Carte adi Ciel cos it looks ugly. :) i might offer Stellarium some cash to remove thir free source software and licence it to me.

I'd go nicely techno and have each mount carry a user code and you would have to pay for mount software upgrades. Failure to pay would mean the mount would go inactive if you don keep up your subscription. Its what Norton does and no stops paying for that. Nice earner there.

The woud be transfer fees for second owners and periodicallly I would bring out a new product that means you not only have to swap the mount out you'd probably have to buy a new telescope as well. Hmmmm maybe not but the rest of it for sure. :)

So you see...be careful what you wish for....you may get it and a nasty shark like me may make you regretful for wishing....

So let your heart sing out

Serial is good

Serial is free

Serials the one

For Astronomy

:). :)

Link to comment
Share on other sites

But back in 2001 when these mojnts started shipping a lot of users would have had no 100 Base Card. 100Base ethernet was very slow to take off you know. i worked for a cpmpany bonded to Intel at the time and we had a lot of grief becaue Intel kept stressing about how slow the takeup was.

Wandering off on a tangent a little...

I'm really surprised to hear that. I don't doubt what you're saying, but my experience was just very different. In '96 the company I worked for was setting up networks using CDDI in the core network and 100baseT to the desk. CDDI gave way to FDDI for a while and presumably later on to gigE. The place I was working at in 2000 had multiplexed 100baseT connections to servers to get enough bandwidth. It's interesting that even later than that Intel were still stressing over the uptake of 100baseT.

I had a 128k leased line to my house in '97 or '98. It did come with the job, though.

James

Link to comment
Share on other sites

James.......going well off topic here but :)

I agree and even before then I was selling FDDI networks with fast ethernet ( as it was called then ) to places like Atomic Energy Authority, Met Office etc and as time went by I started flogging stuff to the City like Gigabit Ethernet, Cisco 7000 routers with high speed backplanes for ultra quick apps. There were always some customers at the very edge using the latest and greatest.

BUT the bread and butter up to 2000 was 10baseT.

You wouldnt make a living in netwoeks selling just high end because the volumes jusy didnt exist. Yes I could turn a flashy sale some high speed stuff, FDDI, ATM, Cisco 7000 etc but without the bulk sales of 10base, line drivers, modems, 10base hubs and even 10base2 transceivers I would have been eating a lot of beans on toast :)

When Intel released the 10/100 Pro card everyone assumed it would sell like life to a dying man but it had a horribly slow take up. The reasons were multifarious, 100base limited the run lengths forcing users to adopt switches and bridges into the network and that had a huge cost impact for a lot of companies. Not many were fibred up. It wasnt till about 2003 that run rates really picked up on 10/100 stuff. The early stuff all had a price premium as well, the biggest selling network card back then was the 3Com 3c509 10mbs card and lots of companies were loathe to move off it because of its multi protocol support. It was hard work in 2000 to convince folks they really werent ever likley to use DEClat or VIP tunnel as a protocol and many folks were sceptical that IP would ever overtake IPX ........i can well remember the arguments in various companies about it. It seems comical now.....i can also remember when ai was flogging the Kalpana Ethernet Switch...the first commercially available switch at a mere grand per port. People would argie incessantly that it wasnt a valid bit of kit because it didnt exist as a device in the original 802.3 specs.

Outside the techy companies orthose with a real need for performance low tech ruled. Heck as late as 2004 I wascoming aross companies that were still running DEC VT100 type terminals and where I work now we only just got as far as Win XP and Outlook.

Looking back the amount of technologies that came and went , and are now in the science museum ( yes really) is quite astounding. Somewherein my lock up I have a Motorola Codex Model C modem.....its as big as a tower PC and ran at a whopping 9.6 kbps. I am keeping it as a relic of my Halcyon days and a reminder that whats hot and techny now is simply tomorros junk and recycle waste but you know whats interesting ? With a serial port you cpuld still talk to it.......i think you'd struggle a bit more to connect to an old Madge Token Ring bridge I have as well :)

Link to comment
Share on other sites

Oooh, Trailblazer modems for goalposts :)

If you were selling to the Met Office in Bracknell they were just down the road from us at the time. We were sandwiched between Siemens and Oracle if memory serves. I have to admit to hanging on to my 3Com NICs for as long as possible. They were absolutely rock solid.

Very interesting to hear your side of the story though. We must have been quite advanced all things considered. It certainly didn't feed like it :)

James

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.