The constant MULT will change the duration of the note. Currently, notes are based on 1 second whole note, so a quarter note = 250ms and so on. Higher numbers play the song slower.
The constant VOLUME adjusts the volume of the speaker. I started it set at 50, but that was annoyingly loud. 25 was too quiet.
https://github.com/ronaldroe/ringo-jingle-bells
Statistics: Posted by ronaldroe — Sat Dec 24, 2016 1:27 am
]]>
I want to share my particular version of Ringo_Preloaded_Behavior_V06
I aded new Battery level read routine and do some minor modifications on original (and great) demo files:
____________________________________Changes implemented by AngoLito in this version_____________________________________
a) Behavior 1 - Drive With Remote
* Pressing On/Off IR button (15) switch Off all led (after join with "A", "B" or "X" buttons you can Off all Leds)
* Pressing PlumGeek IR button (16) toogle White lights On/Off (nice to drive in a dark room!)
* Now with "Up" and "Down" keys Ringo runs until another direction key are pressed or "play" IR button (20) is pressed
b) Behavior 8 - Maintain Heading
* New line add that allows stop motors if you leave Behavior 8 with "menu" button when Ringo are turning
c) Behavior 11 - Reading battery level (NEW)
THIS NEW FUNCTION REQUIRES TO SOLDER 47KOhm ON NON MOUNTED R55; IF R55 IS NOT PRESSENT, ALWAYS READS MAXIMUM CHARGE
R55 is located near of Ringo edge at left side of Neopìxel 2 (botton center), is easily accesible
This new function is a simple mode to show battery level; is not accurate, but give you a valid value
Battery measursament is called pressing PlumGeek IR button (16)
d) On power On show Battery level instead PlayStartChirp
e) Changed indicator for "Menu" mode: 1 second flash rear pixel modified for "moving" style flash indicator (nice but more battery drain!) You can comment / uncomment blocks to choose
ATTENTION: To read battery level is necessary to solder a 47KOhm on non populated R55. Must use SMD 0603 or 0402 package.
If R55 is not placed, routine always will read maximum value.
PLEASE CAUTION:
R55 are easily accesible, but you need some experience on solder SMD to avoid damage PCB or nearby components. If you are not an electronic technician or have not experience, perhaps better to asking for help a colleague (i damaged one pad of R55 soldering a cable to connect a external potentiometer when testing... 
)SWITCH OFF RINGO BEFORE SOLDER R55
I attached a ZIP file with Ringo_PreLoaded_Behavior_V06_ReadBatt file; a copy of PlumGeek files with modifications described previously.
It works OK in my Ringo; I do not think there is any problem, in any case you are free to contact with me in this topic
Practice, learn and enjoy...
AngoLito
Statistics: Posted by AngoLito — Sat Jun 04, 2016 7:38 pm
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
Going the route you suggest in paragraph #4 is conceptually different from what I want to accomplish, though I did try that earlier just to see if I understood the functions themselves.
INSTEAD I have made some [partial] progress by going the following route:
In the Behaviors tab, for cases 11, 14, 12, & 13 I deleted the MoveWithOptions() and the RotateAccurate() functions and substituted Motors() function statements, respectively
Motors(150, 150) for fwd case 11
Motors(-150, -150) for reverse case 14
Motors(0, 75) for left case 12
Motors(75, 0) for right case 13
and since all the flashing leds and chirps are not of particular interest to me here, I re-purposed case 21 as follows
case 21: // "X" key, stop motors
PlayChirp(NOTE_C7,100);
Motors(0, 0);
delay(10);
OffChirp();
break;
The net effect of all this is that after button1 initiates the newly defined DriveWithRemote block, pressing any of the directional arrows on the IRRemote will initiate a continuous [motor] behavior in the expected direction. Pressing another arrow key will substitute that new direction for the previous one, and pressing the "X" key stops Ringo.
I am experiencing what I think may be a Ringo hardware limitation. Ringo itself [does it have a gender?] only receives/acknowledges/accepts a fraction of the IRRemote button presses we make. This makes Ringo's on-the-floor behavior VERY UNRELIABLE and for my grandsons VERY FRUSTRATING. Is this curable in software [adding a delay or some such]??? Or do we perhaps have bad hardware??
For example, my right arrow and left arrow commands cause Ringo to rotate continuously rt and left. Trying to get Ringo to stop rotating so as to go fwd or rev in a specific new direction is almost impossible. There is over-shoot and just plain non-response to the IRRemote. So, I further re-purposed case 18 ["A" key] and case 19 ["B" key] to allow us to interrupt Ringo from fwd or rev motion and then rotate only a given angle [I am using 45° right now] and then remain stopped so we could determine whether he was pretty much headed the new direction we wanted:
case 18: // "A" key, turn left 45°
NavigationBegin();
ZeroNavigation();
PlayAck(); // flash green fwd LED as acknowledgment of IR command
RotateAccurate(-45, 1000); //rotate 45° anti-clockwise for a max of 1 second
break;
case 19: // "B" key, turn right 45°
NavigationBegin();
ZeroNavigation();
PlayAck(); // flash green fwd LED as acknowledgment of IR command
RotateAccurate(45, 1000); //rotate 45° clockwise for a max of 1 second
break;
I chose "A" and "B" keys for this due to their physical location on the IRRemote - on either side of the up-arrow key.
So far, we love the sophistication in possibilities. Ringo's sensors can accomplish fabulously complex response with extremely good precision — PreLoaded Behavior 10 is fabulous. And having the code for DriveWithRemote in the PreLoaded file to begin with was terrific. I could never have gotten going without all that help!!
But we humans find we cannot drive Ringo with sufficient precision around on the floor due to the unreliability of the IRRemote-to-Ringo 'connection'.
J
Statistics: Posted by jedward — Fri Oct 23, 2015 10:56 pm
]]>
I think this would be possible, and I'm really glad to see someone starting to grow the existing code. I hope to see more of this.
Study the existing drive with remote sketch. A few random thoughts...
While the button is pressed, the remote sends the command over and over. This can tend to flood the IR receive function. I think you would want to introduce a slight delay of maybe a few milliseconds before restarting the IR receive handler after a previous command was received.
You can probably edit the existing drive with remote and make the movements much smaller. Look at the navigation chapter in the guide. This will tell you how the functions in the existing move with remote work. Just make their numbers smaller to get smaller movements.
Ideally, I'd try to reset the receive handler before kicking off the function to actually move, so when you're done with the move, the IR handler has already received and buffered another packet from the remote.
You may want to use the serial print functions to echo out the received IR packet so you can see if it's coming across okay. I do think the existing handler is a bit buggy. Sometimes it misses a packet or receives garbage data. I've put the actual receiving sensor on the scope and there is a good clean signal coming out, so it must be something in software with the IR Receive function. Hopefully I or someone else can have a look at that soon.
Your task is slightly on the complicated side but certainly possible.
-Kevin
Statistics: Posted by Kevin — Thu Oct 22, 2015 4:49 pm
]]>