yes i found that if i didnt send the command quick enough the nunchuck seemed to time out. so thats why i started putting them all on the one line.
Also do your buttons apprear to work correctly. I seemed to be getting some randomness with the 6th byte that is returned which i think is supposed to be the buttons.
I need to check the numbers properly and see if they work out.
Well, doing a bit more playing i definatly get times where the nunchuck comes back with aLL FF values (ie didnt work) and i try it again and it seems to work.
Also i upgraded to v4.1 and it seems the same. going to try 4.2 . but i need to work out what download to use to upgrade the early v4 bootloader to the latest bootloader. might have to pull out my pickit2
7. RAW2WIRE 8. RAW3WIRE 9. PC KEYBOARD 10. LCD (1) >4 Mode selected Set speed: 1. ~50KHz 2. ~100KHz 3. ~400KHz (1) >1 READY I2C>W POWER SUPPLIES ON I2C>P 1. Pull-ups off 2. Pull-ups on (1) >2 Pull-up resistors ON I2C>(1) Searching 7bit I2C address space. Found devices at: 0xA4(0x52 W) 0xA5(0x52 R) I2C>[0xa4 0x40 0x00][0xa4 0x00][0xa5 r:6] I2C START BIT WRITE: 0xA4 ACK WRITE: 0x40 ACK WRITE: 0x00 ACK I2C STOP BIT I2C START BIT WRITE: 0xA4 ACK WRITE: 0x00 ACK I2C STOP BIT I2C START BIT WRITE: 0xA5 ACK READ 0x06 BYTES: 0x78 ACK 0x7A ACK 0x8E ACK 0x64 ACK 0x69 ACK 0x0B NACK I2C STOP BIT I2C>
Now having said that it does seem a bit hit and miss.
Also i found that using the full string on one command line works best
try [0xa4 0x40 0x00][0xa4 0x00][0xa5 r:6]
It seems to work better than splitting them across 2 commands as the nunchyck seems to timeout
I will upgrade the firmware and try some different speeds later
Edit: i have just tried at 100K, seems to work ok. I have noticed that i need to send the command a second time to get it to respond the first time.
after that it seems to respond every time. this is at both 50 and 100Khz
Also just tried it with the V3 BP i have. Other than having to change the connection due to the 3.3v change it works fine. Also i dont have the pullups enabled and it seems ok. so im just using the 4 connections
Im also based in AUS but i have never had an issue getting to the forums.
here is the tracert
Tracing route to whereisian.com [208.43.212.208] over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.50.1 2 8 ms 8 ms 7 ms 10.61.0.1 3 9 ms 10 ms 9 ms 198.142.160.169 4 27 ms 23 ms 23 ms 211.29.156.11 5 183 ms 185 ms 187 ms 203.208.190.149 6 191 ms 191 ms 195 ms 203.208.145.102 7 224 ms 226 ms 222 ms 64.215.81.2 8 224 ms 227 ms 225 ms 66.228.118.209 9 230 ms 230 ms 234 ms 66.228.118.214 10 224 ms 225 ms 229 ms 208.43.212.208
Trace complete.
maybe there is a different route with different isp's. I use Optus cable
nice to see some changes and the more stable manufacturing coming along.
I must admit i have been wondering about the capacitors on your boards lately . My feeling is i am wondering if there is enough capacitance for all occasions.
now dont take this to serious as its only me wondering. i havnt looked into this in a technical way. just a gut feeling after a design i had needed upgrades in the capacitor sizes for stable operation.
since it looks like this forum is starting to get some answers. ill ask a question that i have been dieing to ask since i saw you were developing this.
Is this board either in its current form or possibble via new firmware.
I would love to see a replacement for microsofts MCE remote. I can buy the logitech harmony remotes to control the sending side of things but without the receiver theres not much point.
Now for the bad news. i have tried searching for some specifications for the MCE remote standard. but i havnt found anything. I do know that windows either has drivers built in or doesnt need drivers. so im guessing its a HID device.
Anyway food for thought.
Also one of the features that the genuine remote reveiver has is that it has 2 external IR led's for controlling external devices like settop boxes etc.
Keep in mind that from what i believe the code only has part of the full mac address changeable. Same as the eeprom chips address is only the random portion of the address
The code would have a Microchip assigned portion of the address as static still.
So even if the mac address was the same as another device it should only be another microchip device. SO the chances of having 2 microchip devices with the same randomly generated mac address would be very slim.
And if that did happen there would be no reason why the address couldnt be changed by hand to a known mac address.
As a last resort you could hand solder one of the mac address chips to the board and use its address. This shouldnt take to much hacking as most/all of the needed pins are allready on the current eeprom. about the only thing that might be needed is a second c/s pin.
But if there was a ver 2 of this board, yes i would like to see the eeprom chip on the board by default.
