Blinky Grid Programming

[E3po]

Hey guys!! I got my Blinky Grid kit today and assembled it in about 35 minutes. That included moving ambient light LEDs to the back after I was done to better see what was happening while programming.

I have had no luck getting it to program though. Even trying the suggestions you offered in the forum to other posters. I cannot even get a single letter of text or a single LED in pixel display mode.
I am sure of polarity of leds labeled c and d as the "big side" of each is toward each other and the second led blinks when I try to program.

I read "Blinky GRID doesn't recognize end of data stream?" in the forum and that pretty much describes my results except I tried those suggestions with no luck.

I am using Firefox as my browser, and a dell laptop. I also tried to use my 46" TV as monitor and had same results.

I sent back my PIC programmer as it didn't work for the tactile metronome and ordered a PICkit 2 per your suggestion. That will take a couple of weeks though (ebay from China). I do, however, have a sparkfun FTDI Basic cable for use with Ardweeny and similar (labeled GRN on one side and BLK on the other side). Is that useful for troubleshooting?

What are the open spaces on the board used for? (Blink and PGM LED specifically)

Does it need to be completely dark to program? What do you think is wrong?

[layne]

Hey there! The big thing to check is that the two light sensors are oriented correctly. I think another thread has a good picture where you can see inside the little sensor case to make sure it's oriented correctly (can be hard to tell after cutting off the leads), but you've already done that, so let me think of some more troubleshooting things.

I haven't had any trouble programming in various levels of ambient light, but try to avoid having the ambient light changing during programming. The sensors do some auto-leveling at startup (after you push the button the second time, don'tcha know) that might get thrown off if you turn on/off the lights in the middle of programming.

You did try setting the delay to a painfully-slow 100, right? The led blinks every time it receives a "byte" of data (8 bits, so 8 transitions of the "clock" blinky square). That it's blinking is a good sign. Even with a single character message, it doesn't work?

You're right, that's an FTDI connection, but I think the debugging output of the bootloader is disabled because it wouldn't fit in the chip fully featured and with debugging support. Let me check on which firmware we shipped for the bootloader and get back to you.

Two of the ICSP programming lines (PGD and PGC) overlap with the LED output lines, which can interfere with programming the chip. Since those two pins have to do double-duty, we added a pair of jumper pins to allow us to choose between connecting the chip to ICSP or connecting the chip to the LEDs. By default, the chip is connected to the LEDs, as that's what the customers would want, but we added pins and easy-to-cut traces on the board so you could cut those two traces, solder in those six pins, and use jumpers to select which to connect the chip to. If you want to listen in with the FTDI cable, you'll have to add in those headers and jumper the chip to the "PGM" side.

The "Blink" header is connected to light sensors (and power and ground, too). For a while, before we found the right sensors, I wanted to be able to "blink" over FTDI. This is one way that might work to try and troubleshoot if your trouble is due to just the light sensors and/or somewhere else. Let me dig into my old code tonight to find my "serial blinker" code that basically does the blinking protocol but over a serial port. Then, you'd be able to connect your ftdi cable to the Blink port and sort of override the blinks, I think. I haven't tried it in a while.

Sorry for the trouble you're having with blinky programming, we'll figure it out soon I'm sure!

[E3po]

I have double checked orientation of the sensors and they are correct. According to that other thread, the bigger metal plate (cathode?) is connected to the inside of each and the other (anode?) is connected to the positive on each. And I moved them to the back, the orientation should be the same right?

Should the second LED blink once for each time the clock square blinks? It seems to be much less frequent than that. I seem to get the same results when both sensors are over top of clock square. Should I suspect a bad sensor on the data side? I could desolder it and test it with my meter. Should I switch them? The one in the C position is hazy looking while the D is really clear. Does that matter?

I have been holding the assembled kit at various distances too. As I have yet to have success, that doesn't seem to matter yet either.

I have tried 100ms, 30ms, 55ms, 200ms... the longer (100-200) seems to evoke 3rd and 4th leds to flash.

Could It be a voltage issue? I am using rechargeable (1.2V AAs) cells.

As always thanks!
-e

[E3po]

FYI I tried FRESH 1.5 AA's and no progress
-e

[layne]

You are correct, the larger piece of metal inside the sensors should both be on the "inside" of the board, nearer to the middle and the W&L logo. If you move them to the back, the same applies. Sounds like you are good in this regard.

The second LED should be solidly on until you hit "Go" on the programmer webpage. Then, it should change state every time the clock square has 8 transitions (black->white or w->b). You have good insight that it sounds like a bad sensor on the data side. If there was a bad sensor on the clock side, then the second led probably wouldn't be flashing as it is. The sensors I have sitting in front of me are all clear, maybe one of yours got scuffed up in shipping? It shouldn't matter, I think.

I would hold the sensors so they are touching your monitor (or very close). That's always worked for me.

When the 3rd and 4th LEDs start flashing in the alternating pattern, that indicates a checksum error. The data to transmit is wrapped into "records" containing 16 bytes of actual data, along with the address where they should be placed, and a checksum. The checksum is a way for the Blinky kit to double-check that there weren't any errors during data transmission. If it detects a checksum error, it gives up and starts the blinking on leds 3/4.

I believe the blinky can operate down to 1.8v supply, so your rechargeable batteries should be fine. Thanks for trying them with fresh 1.5v cells too.

At this point, since you certainly sound confident in your soldering/desoldering abilities, I'm going to send you a few more sensors to try out. I'd try replacing the data sensor first, since the clock sensor seems ok. Please email us your mailing address to wayneandlayne@wayneandlayne.com and I'll send those out today.

Thanks for your patience as we sort this out. It's incredibly useful to have a skilled solderer such as yourself help us troubleshoot wonky kits.

[E3po]

Hello guys! I am still without working ambient light sensors

I seem to remember Matthew asking another poster if they had access to a PIC programmer for troubleshooting.

I recently got a PICKit2 and wanted to know if I can change the message with that since I cannot without sensors.
Thanks
-e

[wayne]

E3po,

Could you please private message or use the contact form to send us your name and address again? I'm having some issues getting these ambient light sensors through the postal service, it looks like. I might have to start sending them Fedex or something.

Adam Wolf

[layne]

E3po,

Just to check, but did you ever receive the light sensors in the mail? Were you able to repair your kit and get it working?