First trials - and errors

I received my Pucks today and immediately started to try to give them life.

As I am running Windows 10 i am limited to using the native IDE, but after a few hours I was up and running.

The "Controlling other Pucks" is a great starter sample, but seems to have a few limitations:

1. When the slave Puck is paired with Windows it is not found by the master Puck. I have to unpair in Windows to make it work.
   
2. I tried to meake two pucks connect to each other, but the fist connection seems to disable the reverse connection.
   
   

Both issues probably has to do with BLE limitations. As it is hard to debug an unpaired Puck, I have not been able to dig deeper.

Can anyone help me with this? Do I have to release the outgoing connection on Puck1 to make it accept incoming connections from Puck2?

It's one connection at a time. Once connected the pucks don't continue advertising. There are a couple of other threads in the puck.js forum section, so you may have already found your answers. If not check this thread out http://forum.espruino.com/conversations/297154/#comment13362559

Yeah, it's just BLE.

Basically the Puck can only have one concurrent connection - there's no point in it continuing to advertise once connected, since even if it did it couldn't be connected to.

I'm not quite sure what you mean about Pucks connecting to each other though - you mean flash each Puck with code that tries to connect to the other one when a button is pressed?

That should work fine - as long as you're not connected to either Puck.

Just to add - if you do want to debug while a Puck is being connected to from another Puck, you can use a USB-TTL converter to make a wired connection: http://www.espruino.com/Puck.js+Quick+Start#by-wired-connection

When "trying to connect to each other" i used the code in the "fast" sample which keeps the connection alive. This probably prevents connections in the opposite direction.

I will try again with the "slow" version. Initiating the connection for every button press should probably make it. As long as all sessions are closed properly...

When it comes to debugging, I do not want any hardwiring. I like the feeling of juggling with a handful of Pucks like a pile of casino chips. I want to keep juggling while keeping a few pucks under the loupe. Thats half the charm of Puck (or at least 90%)...

I am trying to make the Puck as expressive as it can be, by using the LED:s for debug output in roman numeral format (I=red, V=green, X=blue).

I am enjoying this. Big time!

:) Thanks!

So you've got some debug arrangement that flashes the LEDs in the right order for different messages?

http://forum.espruino.com/conversations/297206/

I like your Roman Numerals...

If lit at one time, you get 7 messages... 1, 5, 6, 10, 11, 15, 16 If lit

in sequence, you get some more out of it:
1 (I,r), 4 (IV,rg), 5(V,g), 6(VI,gr), 9(IX,rb), 10(X,b), 11(XI,br), 14(XIV,brg), 15((XV,bg), 15(XVI,vgr)... to just name the valid Roman Numbers.

I applied Numerals in Morse Code and used green for good codes throughout the code, and red ones for errors...
1: .---- 2: ..--- 3: ...-- 4: ....- 5: ..... 6: -.... 7:--... 8: ---.. 9: ---- 0:-----

(or: all sequences are 5 flashes long; sequences starting with dot/short flash are 1..5,
starting with long ones are 6 to 9 and 0 (that for sure was defined before digital aera began).

A logger object that knows when console is available or not understands .err(msgString) and .info(msgString), where msgString is, for example, .----: Connected, prints the msg in console or flashes just the LEDs accordingly (using recursion on string ":"[0]). If you need multi digit messages, blank needs its own interpretation).

The overall issue though is how you 'delay' application code continuation when using timeouts to do the blinking in order to prevent time-wise overlap of blinking. The code has to be structured accordingly into 'callable' blocks of which the block to be executed next is passed to the logger as well when overlap can be expected.

I blink the roman "digits" in sequence. With three LED:s numerals up to 50 (the number 40 and 50 twisted by only using X) can be presented by only using short blinks, and with much fewer blinks than morse code.

I handle the "output" using an interval timer, which means that I output only the last "message" encountered. It repeats every three seconds for a minute. After a button click it is reactivated for another minute.

I have encapsulated my simple UI (with code for both input and output) in a handy class, and used it in quite a few hacks.

If someone is interested I can probably encapusate it in a convenient library.

Vroman=5decimal?, Lroman=50decimal?... To get the numbers up to 50, do you blink the numbers multiple times?

Would a 3 LEDs BCD blinked twice provide a system of 99 codes that is easier to interpret? Btw, I wondered if you wanted to use L instead of V in the first place, because V = (invalid) VX, but L and XL is valid, and provides three more codes (max 61) with blinking each LED only once... ;-)

I 'assumed' you compose a valid roman number, but with last post it looks to me that you sum up each blink's color related value... (which is for sure easy...)