OK, will post the circuit when I get home (still at work now).

I'm glad my code helped you... ;-)

1. The device does not respond if I connect the power (wall wart or usb).  Only after pressing reset does everything start working.

Yes, I noticed that too. It seems the Ethernet shield doesn't bring the link up on first power on, only after a reset. No idea if there is a way to fix that. I would be rather interested in a solution to this.

2. After a few hours the device hangs up and the SNMP stops responding.  I can still ping the device but no SNMP until I do a reset.

This sounds like the issue I was describing in my previous post. There seems to be a non-SNMP packet stuck in the buffer that gets processed over and over again. Still looking for a solution but I have a workaround using a watchdog timer (see below).

By comparing the first Weather Station code that I found initially in a previous post and the code in the post above I saw that you added a watchdog timer to the setup routine.  I don't know what a watchdog timer is but I added it and will be testing for stability.  Any tips would be greatly appreciated.

That relates to a hardware watchdog timer I built. It's based on a NE555 timer (but of course! ). It triggers a reset pulse if it did not get a timer pulse for 3 seconds. Let me know if you want the circuit diagram. In the loop() function I pulse the watchdog timer input once every loop if bool reset is false. Then, when a non-SNMP packet is received, I set bool reset to true. This causes the loop not to pulse the watchdog and 3 seconds later the Arduino resets. Bit of a dirty workaround but it works for now.

Also, I noticed that this line is commented out //    Agentuino.responsePdu(&pdu);

I take it that is the line in the SNMP function that handles non-SNMP packets? I did put that in at some point hoping that replying to the non-SNMP packet would get it out of the buffer. It didn't work, so I commented it out (but leaving it there, just in case).

Have had any luck troubleshooting your issues?

Nothing more that what is mentioned above. Too many other projects going on at the moment. The weather station works as it is now, so finding better fixes has low priority. ;-)

The Agentuino library seems to be such a useful tool if it could be polished just a little more.  I wonder if anyone would work on it for a bounty?

Agreed. Though I'm not sure whether the issues are in the Agentuino library or the underlying Ethernet and UDP libraries.. I wonder if LAVco is still working on it?

Thanks a lot, that clears it up... ;-)

I wanted to know if triggering an interrupt on either end would potentially pose a threat to packet integrity.

No. During sending of a character, interrupts are disabled, so that all bits are send together. The are enabled again until the next character needs to be sent. Your interrupt can only fire when interrupts are enabled. It will cause serial data sending to be on hold while your interrupt does it's thing, so you need to make it quick.

Interesting. Does this apply to the hardware serial port only or also to software serial ports (e.g. NewSoftSerial)?
While sending a byte, does the interrupt get lost or does the ISR automatically get called once the byte has been sent?

Hmmm, nobody? I was hoping LAVco would read this... ;-)

Hi Hallmat.

First you need to define whether you want this to be a stand-alone solution or connect it to a computer.

What do you currently have? Does you Dob mount have motors or did you want to motorise it yourself? If it has motors, is there an ASCOM driver?

If it has motors and an ASCOM driver already, then all you need is a guide camera connected to a PC (some webcams will do), free guiding software (such as PHDguide) and a serial cable between PC and and telescope. No Arduino needed in this case.

Without a PC this is going to be a lot more tricky, especially with an Alt-Az mount such as your Dob. I was considering something similar a while ago. I found out that there is a Video Experimenter Shield for the Arduino that can digitise a video source and is able to track objects in the video. You would then need a sensitive enough camera and feed the camera's video into the shield.
However, the resolution of that shield is far to low for the tracking accuracy required for astro photography. See discussion here:
http://arduino.cc/forum/index.php/topic,56049.msg480479.html

Even if the resolution was good enough, there is quite a bit of math involved to calibrate the tracking and then calculate the motor steps required to compensate.

ooooops, for some reason I did not get notified about the replies in this thread. Just now I checked back here because I have another project with the same problem. Only now, half a year later, I've seen all your replies. ;-)

So as I understand it the easiest way is to cut the 5V line from USB and power the Arduino via it's 5V pin. The only (?) drawback is that I would lose the ability to power the Arduino from USB but would still be able to communicate over USB? I could live with that.

I'm afraid I need a little more help with the SNMP library and possibly the underlying Ethernet library...

It's been a while but I've now come back to troubleshooting / debugging my weather station sketch. The problem is that occasionally a received packet gets stuck and is being processes over and over again. I'm not sure what that packet is but it's definitely not an SNMP packet.

What I have done is I added lots and lost of serial port output to the sketch and I keep a machine running to log that output to a file. I have attached both the sketch and the part of the log file that shows the sketch running into the problem.

The problem starts at line 2170 in the log.txt. What is happening is that (for some reason) the Arduino receives an unknown packet from the same IP that usually sends the SNMP GET requests. Since it is not a valid SNMP packet, the following if statement is not true (from line 200 in the sketch):

Code:

  // check if valid packet
  if ( (pdu.type == SNMP_PDU_GET || pdu.type == SNMP_PDU_GET_NEXT || pdu.type == SNMP_PDU_SET)
        && pdu.error == SNMP_ERR_NO_ERROR && api_status == SNMP_API_STAT_SUCCESS )
    {

So the sketch jumps to the following else statement (line 505)

Code:

  else
  // packet not valid, send GENERAL_ERROR response. Required, otherwise the invalid packet
  // will get stuck in the buffer and processed over and over again
 
  {
    Serial << "Unknown Packet!!" << endl;
    Serial << "PDU Type: " << pdu.type << " PDU Error: " << pdu.error << " API status: "<< api_status << endl;
    Serial << "from IP: " << Agentuino.g_dstIP(0) << "." << Agentuino.g_dstIP(1) << "." << Agentuino.g_dstIP(2) << "." << Agentuino.g_dstIP(3) << endl;   
    pdu.type = SNMP_PDU_RESPONSE;
    pdu.error = SNMP_ERR_GEN_ERROR;
//    Agentuino.responsePdu(&pdu);
    Serial << "Sent 'GENERAL_ERROR' response" << endl;
  }

So far so good. However, the next time and all subsequent times I call Agentuino.listen() that same packet is still in the buffer. No further received packets are being processed.

The question is, why does this packet stay in the buffer? Is there a way to flush the buffer from my sketch (or from Agentuino) if an unknown packet is being received? I've been through all the components of the Ethernet library (Udp, Ethernet, W5100, socket) and also the Agentuino library to figure out where and how the packet buffer is released but I couldn't find it.

BTW, the method Agentuino.g_dstIP() is one I added to the Agentuino library in order to get the IP address where the packet came from in an attempt to determine what the nature of the offending packets is.

I just finished building this out and noticed a couple of issues/items.  See attached for image of layout marked up with notes

1) I needed a pull-up resistor (array) between the max7219 SEGs and 2981.  Without this it didn't work at all.  I

That's odd. Works fine for me without pull-ups

2) The cathode 2803 (bottom right in your pic) I had to plug it's ground into the +15v ground.  Using the +5 ground (from the arduino) didn't work

Yes. That ground is the ground for the LEDs. On my build the +5V and +15V have common ground.

3) iset for the 7219 doesn't seem to do anything.  I can run all of this without even a resistor in there

Funny you should mention that. I also built 8x8 LED matrix modules with the MAX7219 (driving the LEDs directly from the MAX) and changing the Iset resistor does seem to do nothing at all. For this particular circuit here I would expect it to have almost no effect as there isn't much current going through the input of the drivers anyway.

That solution already exists.
You can use a webcam or dedicated astro guiding cam and feed the signal into PHDguide for example, which in turn moves the telescope to keep the star on the same pixels.

I was thinking of a stand-alone autoguider without the need for a computer.

Thanks for that. I totally agree with you. I love the Arduino for its low level "hacking"....

It just seems to be underpowered for this particular idea that I had in mind... 

Hmmm I don't think that resolution is good enough...

Do you think it would be possible to increase the resolution by using the shield on a NetDuino Plus or FEZ Domino board?
I guess it would just be a matter of writing a library?


I have no experience with these boards nor with the TVout library yet. I just came across this shield in a Cool Components newsletter and was wondering if it was possible to use it for a stand-alone telescope autoguider.

I have just come across this new shield.

I see it can do object tracking. What is the positioning accuracy? When I feed it a PAL signal from a small camera, what's the tracking resolution of a small white point on a black background (i.e. a star seen by the camera through a telescope)?

Steve, which example are you referring to? I don't see these lines in the example I have (Agent.pde)

a fun thing is that there's no specs on the actual LEDs, only "11-12v" so i'm a little lost on how much current i even need... is there any way to know this? 

P = I * U
=> I = P / U
=> I = 10W / 12V
=> I = 0.833A per LED
(that is assuming that 10W is the input power, not the output power)

These high power LEDs usually need a driver circuit that has an "enable" pin that can be used as a PWM input. So all you need to do is connect the PWM output of the Arduino to the enable pin of each LED driver.

Here is an example of the driver circuit:
http://cgi.ebay.co.uk/High-Power-10W-LED-Driver-MBI6651-PWM-DIM-/380332131049?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item588d8fc2e9