http://talk.jeelabs.net/ Discussion about Jee Labs projects en-US Sat, 31 Jul 2010 11:14:08 +0000 http://bbpress.org/?v=1.0.2 q http://talk.jeelabs.net/search.php http://talk.jeelabs.net/topic/443#post-2421 Sat, 31 Jul 2010 07:17:40 +0000 stef007 2421@http://talk.jeelabs.net/ <p>Yaba,</p> <p>reading the manual does help you know. I don't know how the easy mechanism works but just reading the docs I can see several errors you are making.</p> <p>The error you are experiencing: duplicate packets are not sent by design!</p> <p>Best catch up on:</p> <p><a href="http://cafe.jeelabs.net/man/rf12/rf12_easysend/">http://cafe.jeelabs.net/man/rf12/rf12_easysend/</a></p> <p><a href="http://cafe.jeelabs.net/man/rf12/rf12_easypoll/">http://cafe.jeelabs.net/man/rf12/rf12_easypoll/</a></p> <p>And also this one you don't even call (no idea what effect that will have):</p> <p><a href="http://cafe.jeelabs.net/man/rf12/rf12_easyinit/">http://cafe.jeelabs.net/man/rf12/rf12_easyinit/</a></p> http://talk.jeelabs.net/topic/443#post-2420 Sat, 31 Jul 2010 03:29:47 +0000 yaba 2420@http://talk.jeelabs.net/ <p>Hi all, I wonder if someone could help me, I have the following code, and when I swipe the same card twice, I don't receive anything on JeeLink.<br /></p> <pre><code>void setup() { Serial.begin(57600); Serial.print("[Leitor RFID]"); D_DIR&amp;=~(DATA0+DATA1); rf12_config(); rf12_initialize(1,RF12_868MHZ,212); buzzer.mode(OUTPUT); } void loop() { unsigned char recieve_count=0; unsigned char card_num[4]={0,0,0,0}; unsigned char teste[4] = {0,0,0,0}; for(;;) { unsigned char data0=0,data1=0; if(D_IN&amp;DATA0) //DATA0 incoming signal { data0=1; } if(D_IN&amp;DATA1) //DATA1 incoming signal { data1=1; } if(data0!=data1) // card detected { recieve_count++; if(recieve_count==1) //drop even bit { } else if(recieve_count&lt;10)// card data group 1 { if(!data1) { card_num[0]|=(1&lt;&lt;(9-recieve_count)); } } else if(recieve_count&lt;18)// card data group 2 { if(!data1) { card_num[1]|=(1&lt;&lt;(17-recieve_count)); } } if(!data1) // card data group 3 { card_num[2]|=(1&lt;&lt;(25-recieve_count)); } delayMicroseconds(80); //Data impulse width delay 80us } else // no card incoming or finish reading card { unsigned char i=0; if(recieve_count&gt;= 25) //output card number { recieve_count = 0; //reset flag for(i=0;i&lt;4;i++) { Serial.print(card_num[i], DEC); teste[i]=card_num[i]; </code></pre> <p>card_num[i]=0; //reset card_number array }</p> <pre><code> rf12_easySend(&amp;teste,sizeof teste); Serial.println();// output debug value for (long i = 0; i &lt; 1024 ; i++ ) { // 1 / 2048Hz = 488uS, or 244uS high and 244uS low to create 50% duty cycle buzzer.digiWrite(1); delayMicroseconds(244); buzzer.digiWrite(0); delayMicroseconds(220); } } for(int r=0;r&lt;4;r++){ teste[r]=' '; } rf12_easyPoll(); } </code></pre> <p>} } ` <br /> Example: <br /> Pass card #1 and it returns the id in JeeLink (JL has RF12demo)<br /> Pass card #2 and get it again<br /> Pass card #2 again, and nothing... no packets sent :|<br /> I think i'm messing up with easyPool()<br /> enlight me please :)</p> http://talk.jeelabs.net/topic/433#post-2419 Fri, 30 Jul 2010 13:46:20 +0000 lordmundi 2419@http://talk.jeelabs.net/ <p>thanks so much for all your help. unfortunately, I tried setting the rate delay as high as 20 (not the 100 you suggested but something that should definitely fix the issue), and there was still no change. Also, I tried with the pull-up resistors as Dan suggested.</p> <p>For now we may punt and just use the Wire library with this hardware since figuring this out appears to be eating away at our schedule. If anyone else gets this working on a soft I2C on a Jeenode, <em>PLEASE</em> let us know how you did it!</p> http://talk.jeelabs.net/topic/440#post-2418 Fri, 30 Jul 2010 13:22:44 +0000 gregor 2418@http://talk.jeelabs.net/ <p>OK, here's what I tried: -Reseating CPU: no effect, and I have only this one 328.</p> <p>-Checking RX/TX/SCK etc with a multimeter: Connections appear to be OK, but that does not mean much.</p> <p>-@tankslappa: Got the kit two weeks ago...</p> <p>-Tried to repair/reset fuses following tankslappas link: Both JeeNodes behaved as expected/described in the link, no errors came up. And something has changed: The RF12demo is no longer working on the JeeNode v4 (the JeeNodeUSB, of course, now contains the "repair" sketch). But still, the "repaired" JeeNode v4 does not accept any uploads, error messages are the same as ever. But I think I'll take another look at this "fuses" thing, maybe try repairing once more.</p> <p>Also I'll try to hook up the JeeNode<em>USB</em> to the USB-BUB, just to make sure that the USB-BUB is working.</p> <p>So, thanks again everybody who responded, ideas are still welcome.</p> http://talk.jeelabs.net/topic/433#post-2417 Fri, 30 Jul 2010 09:24:49 +0000 stef007 2417@http://talk.jeelabs.net/ <p>If you set the rate to 9 the i2c port code will use a delay of 9 microseconds. This calculates to 111 Khz. According to the HRMI docs the highest rate supported is 100Khz. You're cutting it close (or to much;-)). I suggest passing something safe as rate/delay for example 100 which would translate to 10Khz?</p> <p>Also did you see Dan suggests that pull-up resistors might be necessary? Perhaps you could try that also if you haven't already.</p> http://talk.jeelabs.net/topic/433#post-2416 Fri, 30 Jul 2010 03:02:01 +0000 lordmundi 2416@http://talk.jeelabs.net/ <p>well, after some experimenting, I was able to get the board up and running with the example code from Dan Julio. I think this proves that the logic levels are ok (Dan suggested they should work with 3.3V and after this test, it seems it should).</p> <p>To get his example code to work on the jeenode, I had to wire up to the SDA and SCL lines on the PSI port instead of trying to make an I2C port using one of the Jeenode "Ports". This let me run his code pretty much unmodified except for having to change the I2C address to one that matched the jumpers I have soldered on the board.</p> <p>But, one big obstacle still remains. This lets me prove the board works, and works over I2C and works with the Jeenode. But for the life of me I still can't seem to get this to work using the Ports library (which I wish I could). Keeping the HRMI wired to the PSI port, I used "Port 0" as it looks like JC has made the Ports library map port 0 to the Arduino hardware I2C lines. I thought that the main issue was the clock rate on the I2C bus, but even with setting this to 9 in the constructor, still getting garbage from the Port. I've tried lots of stuff but obviously I'm still missing something. The code is below. Can anyone suggest why this hardware works with the wire library but won't work with the Ports library?</p> <pre><code>#include &lt;Ports.h&gt; #include &lt;RF12.h&gt; // needed to avoid a linker error :( PortI2C myport (0, 9); // the default clock may be too high. use 100 KHz DeviceI2C hrmi (myport, 0x3f); // address for pin OP7 soldered void setup() { Serial.begin(57600); Serial.println("\n[HRMI]"); } void loop() { // request 1 reading (3 bytes total) hrmi.send(); hrmi.write('G'); hrmi.write(1); hrmi.receive(); byte value1 = hrmi.read(0); byte value2 = hrmi.read(0); byte value3 = hrmi.read(1); hrmi.stop(); Serial.print(value1, DEC); Serial.print(" "); Serial.print(value2, DEC); Serial.print(" "); Serial.println(value3, DEC); delay(1000); } </code></pre> http://talk.jeelabs.net/topic/442#post-2415 Thu, 29 Jul 2010 20:31:59 +0000 yaba 2415@http://talk.jeelabs.net/ <p>excelent work. thanks</p> http://talk.jeelabs.net/topic/442#post-2414 Thu, 29 Jul 2010 19:54:29 +0000 tankslappa 2414@http://talk.jeelabs.net/ <p>Well he admits to pinching the images from fritzing under CC, which I don't think permits him to copyright his work in a restrictive way... So in theory as long as I credit him too, I can pinch his... Looks like he's got part of the microcontroller cheat sheet in there already too.</p> http://talk.jeelabs.net/topic/442#post-2413 Thu, 29 Jul 2010 19:49:39 +0000 stef007 2413@http://talk.jeelabs.net/ <p>Great:-)</p> <p>Ok if someone could just integrate this into a JeeNode cheatsheet like this one below for Arduino.... Just kidding, that would be a lot more work and getting the authors permission and hopefully the source document. But still the cheatsheet is usefull also for JeeNode developers so I thought I put the link here.</p> <p><a href="http://sites.google.com/site/mechatronicsguy/arduinocheatsheet">http://sites.google.com/site/mechatronicsguy/arduinocheatsheet</a></p> http://talk.jeelabs.net/topic/442#post-2412 Thu, 29 Jul 2010 19:33:43 +0000 tankslappa 2412@http://talk.jeelabs.net/ <p>Thanks for the input, I've incorporated your suggestions and corrected the mistake! Thanks for the heads up.</p> <p>Hopefully the link will remain the same, if not I'll code back and update here.</p> <p><em>update</em></p> <p>Guess what... URL changed... I'm going to put it up on my server instead... And PDF it too. <a href="http://www.ishootpictures.co.uk/atmega-pins.gif">http://www.ishootpictures.co.uk/atmega-pins.gif</a></p> <p><a href="http://www.ishootpictures.co.uk/atmega-pins.pdf">http://www.ishootpictures.co.uk/atmega-pins.pdf</a></p> http://talk.jeelabs.net/topic/442#post-2411 Thu, 29 Jul 2010 19:18:09 +0000 stef007 2411@http://talk.jeelabs.net/ <p>Nice work tankslappa! Something to print and put on the wall;-)</p> <p>A small addition usefull for people that want to use the hardware I2C support of the chip:</p> <p>Add (SCL) in between PC5 and "Analog 5 PSI5"</p> <p>Add (SDA) in between PC4 and "Analog 4 PSI4"</p> <p>Personally I would also indicate the SEL0 and SEL1 of the SPI port. They are not known by the atmega as being "SPI device selectors" but JC provided them to add support for additional SPI enabled devices on the SPI port (I presume). BTW you mislabeled those in the drawing: ISP8 should be ISP7 and ISP9 should be ISP8.</p> http://talk.jeelabs.net/topic/442#post-2410 Thu, 29 Jul 2010 17:34:18 +0000 tankslappa 2410@http://talk.jeelabs.net/ <p>After seeing a few questions and comments about putting non JeeLabs bits onto JeeNodes, and having done it myself a few times, I thought one of these might be useful...</p> <p>Basically it's a pin diagram of an ATmega. All the pins are labelled with all their known names. The Arduino names, the JeeNode names, and anything else I could think of whilst I was doing it!</p> <p>Thanks to Stef007 for his fantastic link <a href="http://tinkerlog.com/2009/06/18/microcontroller-cheat-sheet/">http://tinkerlog.com/2009/06/18/microcontroller-cheat-sheet/</a></p> <p>I combined this with info from <a href="http://cafe.jeelabs.net/lab/jn4/JeeNode-v4.pdf">JC's Jeenode V4 PDF</a>...</p> <p><a href="http://farm5.static.flickr.com/4087/4840782367_224bfea12b_o.gif">http://farm5.static.flickr.com/4087/4840782367_224bfea12b_o.gif</a></p> <p>The ports are labelled JP followed by the port number, then A for analogue or D for digital. The interrupt pin is shared across all the ports so labelled JPint. The pins to the ISP are labelled, which are common to all the ATmega based board. The JeeNode then added two extra pins, 8 and 9 which give access to the Arduino digital 8 and 9.</p> <p>Hope this is helpful.</p> http://talk.jeelabs.net/topic/440#post-2409 Thu, 29 Jul 2010 17:25:29 +0000 tankslappa 2409@http://talk.jeelabs.net/ <p>@gregor - Now <em>that</em> does sound like one of the misconfigured ATmegas!</p> <p>Have you had these for a few months by any chance?</p> http://talk.jeelabs.net/topic/440#post-2408 Thu, 29 Jul 2010 16:33:38 +0000 gregor 2408@http://talk.jeelabs.net/ <p>Thank you all very much, I will try all suggestions and let you know. The strange thing is, I get exactly the same upload errors when there is no JeeNode attached to the USB-BUB.</p> http://talk.jeelabs.net/topic/440#post-2407 Thu, 29 Jul 2010 13:18:05 +0000 tankslappa 2407@http://talk.jeelabs.net/ <p>It could be that you've got one of the ATmega's that had the fuses set incorrectly from a month or two back. Luckily as you have a working JeenodeUSB there is an easy way to fix it.</p> <p>http://news.jeelabs.org/2010/06/09/repairing-a-faulty-atmega/</p> http://talk.jeelabs.net/topic/441#post-2406 Thu, 29 Jul 2010 03:24:08 +0000 szac 2406@http://talk.jeelabs.net/ <p>Worked! Thanks!</p> http://talk.jeelabs.net/topic/433#post-2405 Wed, 28 Jul 2010 20:47:31 +0000 Rowfast 2405@http://talk.jeelabs.net/ <p>Would this work? a Step-Up Breakout like this http://www.sparkfun.com/commerce/product_info.php?products_id=8999? anyone experience with it or similar? Thanks!</p> http://talk.jeelabs.net/topic/440#post-2404 Wed, 28 Jul 2010 20:24:55 +0000 tor 2404@http://talk.jeelabs.net/ <p>Try reseating the CPU - fixed my identical problem. If not try swapping the CPU (if you have a spare)</p> http://talk.jeelabs.net/topic/440#post-2403 Wed, 28 Jul 2010 20:22:32 +0000 tor 2403@http://talk.jeelabs.net/ <p>--deleted</p> http://talk.jeelabs.net/topic/433#post-2402 Wed, 28 Jul 2010 19:15:20 +0000 Rowfast 2402@http://talk.jeelabs.net/ <p>Thanks, this is also helping my project. http://talk.jeelabs.net/topic/70#post-2333</p> http://talk.jeelabs.net/topic/440#post-2401 Wed, 28 Jul 2010 17:33:44 +0000 stef007 2401@http://talk.jeelabs.net/ <p>I'm probably not the best person to help you. But better something then nothing;-) So your TX and RX lines seem to work. Another important line is the reset/DTR line. Try opening and closing the arduino IDE serial monitor several times. Each time the jeenode should reset and you should see the rf12 demo help output.</p> http://talk.jeelabs.net/topic/441#post-2400 Wed, 28 Jul 2010 17:25:57 +0000 stef007 2400@http://talk.jeelabs.net/ <p>Hmmm what if your calls to rf12_recvDone() in your switch statement return true? In other words what if the rf12 did receive something? The next time you call it the rf12 might receive another packet or nothing anymore. Perhaps that way you are loosing packets?</p> http://talk.jeelabs.net/topic/441#post-2399 Wed, 28 Jul 2010 16:27:40 +0000 szac 2399@http://talk.jeelabs.net/ <p>If I wrap the rf12_recvDone block at the end in while(1), I'm able to skip through the steps remotely. Seems like it's looping too fast for the rf12_recvDone function to get data. Anyone have any suggestions or improvements? Thanks!</p> <p><code> totalsteps = 3; while(step&lt;=totalsteps) { switch (step) { case 1: if (!(cyclecount % 1)) { //only update display each 1000th time thru loop //TODO increase value when process is running fast (ie checking time properly)</code></p> <pre><code> float currenttemp1F = sensors.getTempC(sensor1); float currenttemp2F = sensors.getTempC(sensor2); stepData buf; buf.rfcurrenttemp1F = currenttemp1F; buf.rfcurrenttemp2F = currenttemp2F; rf12_recvDone(); if (rf12_canSend()){ rf12_sendStart(0, &amp;buf, sizeof buf); } cyclecount++; } break; case 2: if (!(cyclecount % 1)) { //only update display each 1000th time thru loop //TODO increase value when process is running fast (ie checking time properly) float currenttemp1F = sensors.getTempC(sensor1); float currenttemp2F = sensors.getTempC(sensor2); stepData buf; buf.rfcurrenttemp1F = currenttemp1F; buf.rfcurrenttemp2F = currenttemp2F; rf12_recvDone(); if (rf12_canSend()){ rf12_sendStart(0, &amp;buf, sizeof buf); } cyclecount++; } break; case 3: if (!(cyclecount % 1)) { //only update display each 1000th time thru loop //TODO increase value when process is running fast (ie checking time properly) float currenttemp1F = sensors.getTempC(sensor1); float currenttemp2F = sensors.getTempC(sensor2); stepData buf; buf.rfcurrenttemp1F = currenttemp1F; buf.rfcurrenttemp2F = currenttemp2F; rf12_recvDone(); if (rf12_canSend()){ rf12_sendStart(0, &amp;buf, sizeof buf); } cyclecount++; } } if (rf12_recvDone()) { //Serial.print(remoteincoming-&gt;jtChooseMenuItem); remoteControl* remoteincoming = (remoteControl*) rf12_data; Serial.print("rf12_recDone"); if (rf12_crc == 0) { if (remoteincoming-&gt;jtChooseMenuItem == '3') { if (testmode == 1) /// in testmode this will allow me to skip to the next step and is configured elsewhere { digitalWrite(PinElementHlt, LOW); digitalWrite(PinPumpHlt, LOW); digitalWrite(PinPumpMT, LOW); digitalWrite(PinMotorMT, LOW); step++; msgdisplayed=0; timercalculated=0; // next step's timer not yet calculated } } } } </code></pre> <p>} //end loop </p> http://talk.jeelabs.net/topic/438#post-2398 Wed, 28 Jul 2010 13:53:00 +0000 fishy6969 2398@http://talk.jeelabs.net/ <p>Epokh - any help would be appreciated!</p> http://talk.jeelabs.net/topic/440#post-2397 Wed, 28 Jul 2010 11:21:19 +0000 gregor 2397@http://talk.jeelabs.net/ <p>I built the JeeNode v4 from the wireless starter pack. It appears to work: Upon connecting it via the USB-BUB the expected messages ("Available commands: etc...") are appearing. I can use the preloaded RF12demo and send and receive to/from the JeeNode.</p> <p>However, I cannot upload a new sketch to the JeeNode v4: I uploaded the "JeeNodeIoCommander" sketch to the JeeLink and the JeeNodeUSB without problems, but not to the JeeNode v4.</p> <p>Additional info:</p> <p>I'm trying to upload to the JeeNode v4 via USB-BUB (set to 3.3V), the JeeNode is <em>not</em> connected to an additional power source (this should work, correct?).</p> <p>I'm using Arduino IDE, "Board" is set to "Arduino Duemilanove or Nano w/ Atmega328"</p> <p>The upload command is "[path]avrdude -C[path]avrdude.conf -v -v -v -v -pm328p -cstk500v1 -P/dev/ttyUSB0 -b57600 -D -Uflash:w:[path]nodeIO.cpp.hex:i "</p> <p>Error messages (in the IDE and in a terminal): avrdude: ser_recv(): programmer is not responding avrdude: stk500_recv(): programmer is not responding</p> <p>Chances are I messed something up during soldering. Keeping in mind that the JeeNode v4 appears to work, can anybody give me hints to narrow down or localize the reason why an upload fails? For example, checking certain connections on the board, measuring voltage on specific points?</p> http://talk.jeelabs.net/topic/435/page/2#post-2396 Wed, 28 Jul 2010 09:24:21 +0000 tankslappa 2396@http://talk.jeelabs.net/ <p>@stef007</p> <p>22uA now you are showing off! I didn't mean go purely solar. Use solar to top up a battery. Then you wouldn't need to remember to charge it come the end of the decade :-)</p> <p>With that level of consumption you could even do it with a capacitor, although it will have to be a posh one to prevent it leaking all the charge internally over night.</p> <p>A 12v panel however might generate enough to get the charger working (I just checked one here, and sitting on the table out of direct light, it was generating 5.6v - all be it to no load). It really depends on how much light your room gets and what colour it's painted!</p> <p>Don't worry, I'm just thinking random thoughts aloud! If you live in some crazy Northern place like North Norway it probably wouldn't survive those winter nights that last weeks/months! Maybe wind power might be an idea... :o)</p> http://talk.jeelabs.net/topic/435/page/2#post-2395 Wed, 28 Jul 2010 07:06:18 +0000 stef007 2395@http://talk.jeelabs.net/ <p>@tankslappa,</p> <p>27,3 microAmps is the average power usage: most of the time power consumption is that of sleep/powerdown of the atmega at 22 microAmps. Then there are peaks of 7-9 mA (atmega alive) and 25 mAmps (transmitting). So not sure that a little solar panel with indirect light could pull that off?</p> <p>Also, what at night? My sensors must keep running so that I can pull nice graphs in the morning;-)</p> http://talk.jeelabs.net/topic/435/page/2#post-2394 Tue, 27 Jul 2010 23:47:32 +0000 tankslappa 2394@http://talk.jeelabs.net/ <p>With consumption levels that low due to good power management you could put a little solar panel on there and receive enough charge from indirect light to never go flat.</p> http://talk.jeelabs.net/topic/435/page/2#post-2393 Tue, 27 Jul 2010 23:03:32 +0000 stef007 2393@http://talk.jeelabs.net/ <p>@edwardhorsford,</p> <p>it's just the temperature of a room in my house. You're right that I don't need so many readings. I just try to get the most use out of the battery: the shelf life of the 3.6V 2400mAh omnicell I'm using is 10 years. So calculating a bit I can consume about 27.3 microAmps for 10 years. If I consume more than this then the battery will not last 10 years. If I consume less than this the battery might self-discharge anyway and finish at or before 10 years (the estimated shelf life). That's why I target 10 years and increment the frequency of tranmissions if I've got room.</p> <p>I'm using the ds1820 like in the rooms node. But don't worry: JC's demo code has a delay in there when waiting for the temperature calc/fetch. I've put a powerdown/sleep there instead.</p> <p>About caching temperature readings: in my case I don't necessarily want each and every reading. I just want to have a value in my server/NAS which is very up-to-date or at least as fresh as possible (when battery life allows it).</p> http://talk.jeelabs.net/topic/435/page/2#post-2392 Tue, 27 Jul 2010 22:07:26 +0000 edwardhorsford 2392@http://talk.jeelabs.net/ <p>@stef007 - What's this application for? Environmental temperature won't change all that often to make it worth reading too frequently.</p> <p>Some other thoughts: What kind of temperature sensor are you using? Is it optimised so that the microcontroller isn't on whilst it's taking readings. Since most of the cost is in the overhead and in waiting for the radio to power up, is there anything stopping you caching several temperature readings for 500 seconds, then sending a single transmission far less regularly?</p> http://talk.jeelabs.net/topic/435#post-2391 Tue, 27 Jul 2010 21:49:34 +0000 stef007 2391@http://talk.jeelabs.net/ <p>@edwardhorsford,</p> <p>I've tested your rf12 control commands for lower bitrate: it seems that the total transmission time (rf12wakeup-send-rf12sleep) increases by a factor 2. For example:</p> <p>payload of 2 bytes (thus excluding overhead): it takes 4 milis on regular rf12 mode and 7 to 8 milis with your rf12 control codes active. I'm measuring using the global milis counter so it's not super precise but good enough for me.</p> <p>When I incremented the payload to 8 bytes the normal mode took 5 milis and the "slow-but-extended-range" mode took 10 milis. So that seems to be consistent.</p> <p>In practice this meant my temp sensor running on a 2400mAh omnicell would run 8.4 years instead of the 10 years I optimized the "alive" time for. By halving the temperature measure and transmission frequency I got back to my 10 years lifespan.</p> <p>My sensor would wake-up every 37 secs, measure and transmit its payload. Now I let it sleep for double the amount of time, 74 secs. Extending my range costs me either more batteries or less frequent sensor readings.</p> <p>Now I only need to find some time to confirm your findings: is the range effectively extended and, more subjectively, is it worth the less frequent readings.</p> http://talk.jeelabs.net/topic/439#post-2390 Tue, 27 Jul 2010 21:24:47 +0000 tankslappa 2390@http://talk.jeelabs.net/ <p>Arduino Digital 11 is a PWM enabled pin, maybe the code is using the bit shifting ability of the pin. If so then you'll need to use the right port on the jeenode as only two of them have digital pins which can do PWM. Ports 2 and 3.</p> <p>Port 2 is Arduino digital 5 (ATmega pin 11). Port 3 is Arduino Digital 6 (ATmega pin 12).</p> http://talk.jeelabs.net/topic/439#post-2389 Tue, 27 Jul 2010 21:13:11 +0000 jeroen 2389@http://talk.jeelabs.net/ <p>thx guys, I tried one of the jeenode digital pins for the transmitter. That did not work. I will have to dive deeper in the code. (even without JC here the response is great)</p> http://talk.jeelabs.net/topic/435#post-2388 Tue, 27 Jul 2010 20:51:49 +0000 tankslappa 2388@http://talk.jeelabs.net/ <p>My payload isn't very optimised really. I send two bytes. The first is the command to say "fire" the second is a group/channel number which all the flashes belong to. This is purely to allow multiple systems to work side by side without cross triggering. At the moment that isn't an issue as I'm the only one with it, but I thought it was something I really should include.</p> <p>The actual power settings for each flash is sent in advance when you change the levels on the controller. The remotes store this in a variable and in their Eeproms so it's retained through battery changes, power cycles etc.</p> <p>Given I'm still using the standard RF12 library calls to send the message, complete with its 9 byte overhead, optimising my message from 2 bytes to 1 really didn't seem worth it.</p> <p>I really am going to have to bite the bullet and take control of the entire message and not just leave it all down to the RF12 library!</p> http://talk.jeelabs.net/topic/435#post-2387 Tue, 27 Jul 2010 20:23:21 +0000 edwardhorsford 2387@http://talk.jeelabs.net/ <p>As mentioned in this thread: http://talk.jeelabs.net/topic/191 I did do a bit of work at increasing speed. There's a fair amount of optimisation that can go on, but not much that doesn't require significant mods to the RF12 library.</p> <p>I might get around to looking at the RF12 library again from the speed perspective, as the needs of a photographic trigger are quite different than it's default use case.</p> <p>Tankslappa - out of interest, what size of payload are you sending? What's in your payload?</p>