@Tamás Fábián: will you please be kind to me and Christian and tells us if future Sbrick firmware could handle that? I believe there are several ways, the easiest/lazyest perhaps mine: giving a list of n values to send to each port (simillar to LEGO ControlCenter from the 90's) and a step length... so with 16 bytes for each port it woul be neeeded 64 bytes in the SBrick to store the 4 sequences + 1 byte to store the step length.
We are all impatient for the 2.0 version :)
@Christian Treczoks: I believe you want something like this but with a better transition from led to led
https://www.youtube.com/watch?v=mY8iqgo0zvk
I'm using just 3 PF Lights because my Beta SBrick never worked with the 4 channels. I'm sending to each port square values (1,4,9...225,256, 225... 9,4,1) but not doing the transition you want.
I'm not using delays at all because the way I talk to SBrick uses a python call to an external command (gatttool from BlueZ Bluetooth stack for Linux/Android). That's very unefficient and slow but I didn't yet find a python library for Bluetooth Low Energy and SBrick still misses an API/SDK/whatever.
This python script was running on my Ubuntu laptop, it also works in Mindstorms EV3 with ev3dev. I'll try later with a Raspberry with Raspbian, not sure if BlueZ 5 is already included in Raspbian.
-- edit --
Now with a better transiction effect
I believe it will be possible, with a better firmware. Al least something very close to your request.
Except the client app for iOS and Android there is nothing at all. But the same python scripts I've been using in Ubuntu and ev3dev should also work with Raspbian so you could write a loop in python to do want you want (those 0.25 ~ 0.50 Hz frequencies are low enough to use time.sleep to control the timings - perhaps even just a shell script could do it, no python at all).
In fact... I have 4 PF LEDs at home... just give me a day or two, OK?
[blockquote]Jorge Pereira said:
For smaller and cheaper uses a Raspberry Pi is better - just need to add a USB BT 4.0 dongle, a microSD card and a wall charger with USB output.
[/blockquote]
Oh, there is an SBrick control software or library for the Raspberry, too?
But apart from that, is what I asked for possible with the SBrick?
[blockquote]Christian Treczoks said:
Would it be possible to make the SBrick do this on its own, with the bluetooth controller just used to switch this program on and off? It would be a waste to have a smartphone running an application just to keep the lighthouses' light circling all day...
[/blockquote]
You might consider using a spare laptop with BT 4.0 (or add a USB BT 4.0 dongle).
For smaller and cheaper uses a Raspberry Pi is better - just need to add a USB BT 4.0 dongle, a microSD card and a wall charger with USB output.
Or if you already have a LEGO Mindstorms EV3, just add a USB BT 4.0 dongle and a microSD card with ev3dev for an all-LEGO solution.
For one project I would need four PF outputs producing changing PWM levels for LEDs. On a higher level, I need the LEDs' level to be in four waves of identical frequency in the range of .25 to .50Hz and a 90° phase shift. The waveform is that only one LED is at full power, then dims while the next rises, simulating a light moving from one LED to the other. Actually, I'm using four PF LED pairs, so I will have two spots moving around a circle of eight LEDs.
Would it be possible to make the SBrick do this on its own, with the bluetooth controller just used to switch this program on and off? It would be a waste to have a smartphone running an application just to keep the lighthouses' light circling all day...
Hello Nicholas,
This feature is heavily work-in-progress, so we can't demonstrate it now. Our highest priority is to deliver the app with basic function AND the profile designer to all platforms.
Automation features will come after that.
I can tell already that programming the SBrick will be nothing like Mindstorms, because SBrick lacks inputs (no sensors are available... yet ;) ), and the computation / storage capabilities of the hardware are severely limited.
Under "programming" we mean the following:
The details are not fixed yet, so consider the previous list as a teaser. We have a large list of features, and they need to be prioritized properly so we can get the best value for the work done on the SBrick. "Value" of course means what the community considers valuable, and we're facing demands for certain features we did not consider at the time of the Kickstarter campaign.
Actually I'm about to post one right now: "how to use SBrick with an Android phone without BLE support" ;)