Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #40017 > unrolled thread

Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day

Back to article view | Back to comp.lang.forth

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-06-24 14:50 +0200
    Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day JUERGEN <epldfpga@aol.com> - 2015-06-24 13:57 -0700
      Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day Paul Rubin <no.email@nospam.invalid> - 2015-06-24 17:13 -0700
        Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day JUERGEN <epldfpga@aol.com> - 2015-06-25 00:05 -0700
          Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-06-25 15:03 +0200
          Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-06-25 15:51 +0200
        Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-06-25 14:43 +0200
      Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-06-25 15:07 +0200
        Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day JUERGEN <epldfpga@aol.com> - 2015-06-25 10:36 -0700
          Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-06-26 11:15 +0200
          Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-06-26 11:21 +0200
            Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day JUERGEN <epldfpga@aol.com> - 2015-06-26 07:45 -0700
              Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day JUERGEN <epldfpga@aol.com> - 2015-06-26 07:59 -0700
            Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day Paul Rubin <no.email@nospam.invalid> - 2015-06-26 07:51 -0700
              Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day JUERGEN <epldfpga@aol.com> - 2015-06-26 13:10 -0700
                Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day Paul Rubin <no.email@nospam.invalid> - 2015-06-26 13:12 -0700
                Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day JUERGEN <epldfpga@aol.com> - 2015-06-26 14:54 -0700
                  Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day JUERGEN <epldfpga@aol.com> - 2015-07-19 00:30 -0700
                    Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day Paul Rubin <no.email@nospam.invalid> - 2015-07-20 15:18 -0700

#40017 — Re: 1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day

> Thank you very much for your inputs. 
> Short term the TicTac with sticky tape around the top  will protect it. I had it under water already - I had to try it.
> 
> Thank you very much for the links. Is there any code we could re-use?
> All the interfacing is there, and we have additional LEDs. 
> Depends just on the additional time available at the event - or afterwards.

See ledcomm-launchpad.txt in the mainstream release package of Mecrisp. The other ideas are not yet implemented in Forth.

> Ideal setup for GeoCaching I can see.
> 
> I had to define a minimum version though, so it works at the event, and everything else is extension.

Fine.

> The Reed contact was planned already - it was actually part of my first design many many years ago - used as sensor for mains short circuit protection, either flashing for 1h as the LED version or a version two was actually a 200V flash light - all sealed and hanging on a 100kV wire for many years...
> 
> 
> ... and the 128 x 8 byte telegram is a very good option - the HW setup does not change.
> 
> We now have just to find a way to make the nodes adressable - so software can he reloaded onto each unit ...
> 
> And it could definitely be a used as a GA 1024 simulator, just add a couple of wires to define the matrix 2D, 3D ...

Sorry ? What ? I am slightly confused. Maybe posting a schematic of the actual hardware you wish to solder on the event would be a good idea.

Matthias

[toc] | [next] | [standalone]

#40035

On Wednesday, June 24, 2015 at 1:49:28 PM UTC+1, Matthias Koch wrote:
> > Thank you very much for your inputs. 
> > Short term the TicTac with sticky tape around the top  will protect it. I had it under water already - I had to try it.
> > 
> > Thank you very much for the links. Is there any code we could re-use?
> > All the interfacing is there, and we have additional LEDs. 
> > Depends just on the additional time available at the event - or afterwards.
> 
> See ledcomm-launchpad.txt in the mainstream release package of Mecrisp. The other ideas are not yet implemented in Forth.
> 
> > Ideal setup for GeoCaching I can see.
> > 
> > I had to define a minimum version though, so it works at the event, and everything else is extension.
> 
> Fine.
> 
> > The Reed contact was planned already - it was actually part of my first design many many years ago - used as sensor for mains short circuit protection, either flashing for 1h as the LED version or a version two was actually a 200V flash light - all sealed and hanging on a 100kV wire for many years...
> > 
> > 
> > ... and the 128 x 8 byte telegram is a very good option - the HW setup does not change.
> > 
> > We now have just to find a way to make the nodes adressable - so software can he reloaded onto each unit ...
> > 
> > And it could definitely be a used as a GA 1024 simulator, just add a couple of wires to define the matrix 2D, 3D ...
> 
> Sorry ? What ? I am slightly confused. Maybe posting a schematic of the actual hardware you wish to solder on the event would be a good idea.
> 
> Matthias

\ Check in Courier, this is the absolute minimum, but still nicely extendable
\ for beginners - powerful enough to start with, programmable via LP
\
\                 (TOP VIEW MSP430G2553) 
  \ VCC-(+3.3V)---------[01   20]-   2uF to Plus (GND)-VSS
  \              -P1.0--[02   19]--P2.6  
  \ -RXD-Serial->-P1.1--[03   18]--P2.7  
  \ -TXD-Serial-<-P1.2--[04   17]--Test -( programming )  
  \               P1.3--[05   16]--RESET  R to +, C to GND
  \               P1.4--[06   15]-- P1.7
  \               P1.5--[07   14]--P1.6  270R + LED to GND
  \               P2.0--[08   13]--P2.5 
  \               P2.1--[09   12]--P2.4 
  \               P2.2--[10   11]--P2.3 
\ 
\ 2 x AAA battery plus this HW in a TicTac Box as
\ Flashing LED to represent the heart beat of the one who built it
\ ( just occurred to me later it looks like ET )
\ all RXs tied together via 1k each to the master module or LP.
\
\ IOs could be used as bit banged UARTs or SPIs for  
\ interprocessor communication as discussed in the thread
\
\ Via the shield you can extend it for example to be MMT - see www.forth-ev.de
\ Just add 3 switches and 4 R + LED combinations and a loudspeaker.
\ Then you can drive even up to 4 RC servos as shown with MMT
\
\                       (TOP VIEW) 
  \ VCC-(+3.3V)---------[01   20]----------------(GND)-VSS
  \ -AN1 -       -P1.0--[02   19]--P2.6 OUT2 -470R-LED-GND
  \ -RXD-Serial->-P1.1--[03   18]--P2.7 OUT3 -470R-LED-GND
  \ -TXD-Serial-<-P1.2--[04   17]--Test -( programming )  
  \ -S2-----------P1.3--[05   16]--RESET  Switch S1    -- 
  \   AN2-------- P1.4--[06   15]-- P1.7          S3-------
  \ --Sound-Out-- P1.5--[07   14]--P1.6 PWM OUT-----------
  \ >(R to +) IN0 P2.0--[08   13]--P2.5 OUT1 -470R-LED-GND
  \ >(R to +) IN1 P2.1--[09   12]--P2.4 OUT0 -470R-LED-GND
  \ >(R to +) IN2 P2.2--[10   11]--P2.3 IN3 -- (R to +)---<

Is this clear enough now Matthias?

The smallest version in DIL has just 12 x 4 pads, one end of these 4 pins are:
GND - Plus - RX - TX  to connect to terminal - TEST and Reset just used for programming via LP. Uses FTDI USBtoTTL cable to connect to the PC.
Or with just battery connected as flashing unit.

One other requirement that would be nice but somebody still has to do it:
CLONING.
When the kids have written something  they can then just copy the complete 430 code to another one - using the same 6 pins needed for programming - but generated by the master chip via 4 IOs. The Slave does not know where the signals come from and does not care. According to TI this is possible, all of the data seems to be in the relevant application note. No Launchpad required then anymore.
- Or I could always have a backup chip.

The other option might be using a unit to do a bit banged USB in a second chip...

[toc] | [prev] | [next] | [standalone]

#40042

JUERGEN <epldfpga@aol.com> writes:
> One other requirement that would be nice but somebody still has to do
> it: CLONING.... The other option might be using a unit to do a bit
> banged USB in a second chip...

The LEDCOMM idea is brilliant for that.  If I understand it correctly,
it doesn't need any more hardware (or maybe 1 more resistor), but the
LED has to be on an analog pin so you can track its forward voltage
fluctuating according to light exposure.

[toc] | [prev] | [next] | [standalone]

#40046

On Thursday, June 25, 2015 at 1:13:17 AM UTC+1, Paul Rubin wrote:
> JUERGEN <epldfpga@aol.com> writes:
> > One other requirement that would be nice but somebody still has to do
> > it: CLONING.... The other option might be using a unit to do a bit
> > banged USB in a second chip...
> 
> The LEDCOMM idea is brilliant for that.  If I understand it correctly,
> it doesn't need any more hardware (or maybe 1 more resistor), but the
> LED has to be on an analog pin so you can track its forward voltage
> fluctuating according to light exposure.

I suggest P1.4 as input.
What is the hardware setup, and a suggested LED that can be reliably replicated?
Maximum resistor value? We are battery driven here, could use a switched output though.

And Matthias, can you please post code to output a Byte and Input a Byte, 
I assume there are more that would like to look at it.
And for easy testing,to run on the same controller:
IN3 to set low to start the process
PWM as LED out, 
P1.4 as input

As phase 2 then running on two controllers.

[toc] | [prev] | [next] | [standalone]

#40049

Ledcomm is a synchronous bidirectional protocol, pulses are exchanged the whole time. The algorithm is hooked to a timer interrupt, with a default of 244 us, and inserts data into the stream of pulses.

No resistor is needed for MSP430G2553, my favourite LED is Kingbright L-53SRC-F. You should choose a pair of red high-brightness LEDs in clear housing with narrow angle, GaAlAs is fine. You need a direct bandgap semiconductor for Ledcomm in which emission and excitation spectrum overlap. Short: The LED needs to be sensitive to its own wavelength. My experience is that it works with high-brightness red and yellow LEDs, but not with green and blue ones, because they seem to be indirect bandgap semiconductors. You should stick to red because they can operate at lower voltage.

Matthias

This code with German comments is part of the Mecrisp release package and available under GPL3:

compiletoflash

: Sendedatenholen ( -- Daten true | false ) key? dup if key tuck emit then ;
: Datenempfangen  ( Daten -- ) emit ;
: Verbindungsanfang ( -- ) ."  (Up) "      1 p1out cbis! ; \ Verbindungsanzeige nach Bedarf anpassen
: Verbindungsende   ( -- ) ."  (Down) " cr 1 p1out cbic! ;

1 constant Anode
2 constant Kathode

: Strahle ( -- )
  Anode   P2OUT cbis!
  Kathode P2OUT cbic!
  Anode Kathode or P2DIR cbis!   
;

: Lauschen-Vorbereitung ( -- )
  Anode   P2OUT cbic!            \ Sperrschichtkapazität
  Kathode P2OUT cbis!            \ durch Verpolung laden
  Anode Kathode or P2DIR cbis!
  begin Kathode P2IN cbit@ until \ Warten, bis die Kathode geladen ist
  Kathode P2DIR cbic!
;

: Lauschen-Nachbearbeitung ( -- Flag )
  Kathode P2IN cbit@ not        \ Ist die Kathode entladen, ist es hell
;


18 constant Synchrondauer

8 variable Strahlzaehler
0 variable Verbindungsdauer
0 variable Lauschzaehler
0 variable Lichtmuster
0 variable Sendedaten
0 variable Datenregister

true variable Zustand ( Hell oder Dunkel ? )

: msb? ( x -- x Flag ) dup 0< ;

: HolePuls ( -- )
  8 Strahlzaehler ! \ Null-Puls, wird auch im Ruhezustand gesendet.

  \ Verbindungsdauer prüfen, beginne erst zu Senden, wenn die Verbindung auch sicher besteht.
  \ Belasse es im Falle einer gerade laufenden Synchronisation dabei, Ruhezustandspulse abzugeben.

  Verbindungsdauer @ Synchrondauer =
  if
  
  Sendedaten @ ?dup if  \ An bestehender Übertragung weiterarbeiten
                      msb? if 4 Strahlzaehler ! then \ Eins-Puls erforderlich ?
                      shl 
                      dup 0= if 12 Strahlzaehler ! then \ Wurde gerade die Merk-Eins herausrotiert ? Übertragungspuls !
                      Sendedaten !
                    else  \ Neue Daten holen und vorbereiten                     
                      Sendedatenholen
                      if 
                        ?dup if  ( Daten-zum-Senden )
                               4 Strahlzaehler ! \ Bei neuen Daten ungleich Null wird die führende Eins gesendet
                               
                               msb? if \ Ist das MSB schon die führende Eins ?
                                      shl 1 or \ Eine Merk-Eins reinrotieren, die nicht übertragen wird
                                    else
                                      shl 1 or \ Eine Merk-Eins reinrotieren, die nicht übertragen wird
                                      begin
                                        msb?   \ So lange schieben, bis die führende Eins herauspurzelt
                                        swap shl swap
                                      until
                                    then
                                                              
                               Sendedaten ! \ Fertig geschobene Datenbits zum weiteren Senden bereitlegen
                             else 12 Strahlzaehler ! \ Für eine Null genügt ein Übertragungspuls
                             then
                      then
                    then
  then
;

: Bitmustererkennung ( -- )
  Verbindungsdauer @ Synchrondauer <>
  if \ Verbindung besteht erst nach 18 mal Zublinkern stabil.
    1 Verbindungsdauer +!
    Verbindungsdauer @ Synchrondauer = if Verbindungsanfang then    
  then

  Lichtmuster @
      %1111111111100 and    \ Übertragungspuls wird mit 11 bis 14 Basiszeiten erkannt
  dup %1111111111100 = if drop Datenregister @ Datenempfangen 
                             0 Datenregister ! \ Datenregister muss gelöscht werden,
                       else                    \  da die Daten aus mit variabler Länge übertragen werden

          %111111100 and    \ Null-Puls wird mit 7-10 Basiszeiten erkannt
          %111111100 = if   Datenregister @ shl      Datenregister ! 
                       else Datenregister @ shl 1 or Datenregister ! 
                       then \ Eins-Puls wird mit 3-6 Basiszeiten erkannt.
                       
                       then
; 

: Taktlauscher-init ( -- )
  0 Sendedaten !     \ Keine Daten zum Herausrotieren und Abstrahlen ! Wichtig !
  Verbindungsdauer @ Synchrondauer = if Verbindungsende then
  0 Verbindungsdauer !

  Zustand @ if
    \ Für einen hellen Taktlauscher
    HolePuls
    Strahle
  else
    \ Für einen dunkelen Taktlauscher  
    0 Strahlzaehler !
    1 Lauschzaehler !
    Lauschen-Vorbereitung
  then
;

: Taktlauscher ( -- )
  Strahlzaehler @ ?dup 
  if \ Strahlzähler ist nicht Null
    -1 Strahlzaehler +! 
    1- if 
         Strahle
       else \ Gerade Null geworden
         32 Lauschzaehler !
         0 Lichtmuster !
         Lauschen-Vorbereitung
       then
  else
    Lauschen-Nachbearbeitung
    1 and Lichtmuster @ shl or
    dup Lichtmuster ! ( Neues-Lichtmuster )
    %11111 and
    %11100 = if 
               Bitmustererkennung 
               HolePuls
               Strahle
             else
               -1 Lauschzaehler +!
               Lauschzaehler @ if Lauschen-Vorbereitung 
                               else Taktlauscher-init then
             then
  then
;

: ledcomm ( -- )

  Anode Kathode or p2dir c! \ Ausgänge für die Ledcomm-LED und die Verbindungsanzeige
  65  p1dir c!
  64  p1out c!

  Taktlauscher-init
  ['] Taktlauscher irq-timera0 !

  $10  $0162 !
  1953 $0172 !
  $210 $0160 !

  lpm0 \ Enable Interrupts and switch off CPU
;

: bright ( -- ) true zustand ! ;
: dark   ( -- ) false zustand ! ;

compiletoram

[toc] | [prev] | [next] | [standalone]

#40052

> And Matthias, can you please post code to output a Byte and Input a Byte, 
> I assume there are more that would like to look at it.

To get a feeling for Ledcomm, you can try it on various Launchpads and other chips. Mecrisp and Mecrisp-Stellaris packages contain implementations for MSP430G2553, MSP430FR4133, MSP432P401, LM4F120/TM4C123, LPC1114FN28 and STM32L152. All implementations are compatible to each other and across architectures.

Additionally, Ledcomm found its way into ChibiOS: https://github.com/klpauba/LEDComm and http://klpauba.github.io/LEDComm/

Matthias

[toc] | [prev] | [next] | [standalone]

#40048

Paul Rubin schrieb:
> JUERGEN <epldfpga@aol.com> writes:
>> One other requirement that would be nice but somebody still has to do
>> it: CLONING.... The other option might be using a unit to do a bit
>> banged USB in a second chip...
> 
> The LEDCOMM idea is brilliant for that.  If I understand it correctly,
> it doesn't need any more hardware (or maybe 1 more resistor), but the
> LED has to be on an analog pin so you can track its forward voltage
> fluctuating according to light exposure.

No analog input needed, any digital pins are suifficient for that, given they have an input hysteresis. MSP430 pins are current limited, so it works without resistor in this case.

Matthias

[toc] | [prev] | [next] | [standalone]

#40050

> Is this clear enough now Matthias?

Thank you for the schematics. How do you implement networking/communication with this setup ? As far as I recall, you wished to make an art or multi-node display installation which would at least require to keep the nodes in sync.

Matthias

[toc] | [prev] | [next] | [standalone]

#40056

On Thursday, June 25, 2015 at 2:06:21 PM UTC+1, Matthias Koch wrote:
> > Is this clear enough now Matthias?
> 
> Thank you for the schematics. How do you implement networking/communication with this setup ? As far as I recall, you wished to make an art or multi-node display installation which would at least require to keep the nodes in sync.
> 
> Matthias

For now we go minimalist here as well:
One resistor on RX and the other side all connected. 
So just 2 wires to al of them: Ground and RX protected.
They get their personal number when programmed the first time. If something goes wrong or the battery is empty - they are off - but do not disturb the rest.
Simple but fail safe.
More complex will be tried later or if there is time.
As said, a 16 unit test panel is ready.

And the plan is to have the systems - or how many might be left after the event,  via Bluetooth or WiFi connected to the Internet later - the spare time limit will dictate what happens when.

And anybody who asks can have a go at controlling them...

[toc] | [prev] | [next] | [standalone]

#40062

JUERGEN schrieb:
> On Thursday, June 25, 2015 at 2:06:21 PM UTC+1, Matthias Koch wrote:
>>> Is this clear enough now Matthias?
>> Thank you for the schematics. How do you implement networking/communication with this setup ? As far as I recall, you wished to make an art or multi-node display installation which would at least require to keep the nodes in sync.
>>
>> Matthias
> 
> For now we go minimalist here as well:
> One resistor on RX and the other side all connected. 
> So just 2 wires to al of them: Ground and RX protected.
> They get their personal number when programmed the first time. If something goes wrong or the battery is empty - they are off - but do not disturb the rest.
> Simple but fail safe.
> More complex will be tried later or if there is time.
> As said, a 16 unit test panel is ready.
> 
> And the plan is to have the systems - or how many might be left after the event,  via Bluetooth or WiFi connected to the Internet later - the spare time limit will dictate what happens when.
> 
> And anybody who asks can have a go at controlling them...

With the same hardware you could use the "scurry wire" bus. See wuseldraht-scurrywire-0.1.tar.gz on mecrisp.sourceforge.net for more details. It is a field bus I developed for greenhouse applications that can supply power, using a data and a ground wire and you can run a node discovery. But unlike 1-Wire it is capable to deliver much more current, multiple power injection points are possible and it can handle large bus capacitances. If you add a silicon diode as 1N4148 to not overload the internal protection diodes, you could also charge the nodes while they are on the bus.

I will leave today afternoon for two weeks, best wishes for your project !

Matthias

[toc] | [prev] | [next] | [standalone]

#40063

JUERGEN schrieb:
> On Thursday, June 25, 2015 at 2:06:21 PM UTC+1, Matthias Koch wrote:
>>> Is this clear enough now Matthias?
>> Thank you for the schematics. How do you implement networking/communication with this setup ? As far as I recall, you wished to make an art or multi-node display installation which would at least require to keep the nodes in sync.
>>
>> Matthias
> 
> For now we go minimalist here as well:
> One resistor on RX and the other side all connected. 
> So just 2 wires to al of them: Ground and RX protected.
> They get their personal number when programmed the first time. If something goes wrong or the battery is empty - they are off - but do not disturb the rest.
> Simple but fail safe.
> More complex will be tried later or if there is time.
> As said, a 16 unit test panel is ready.
> 
> And the plan is to have the systems - or how many might be left after the event,  via Bluetooth or WiFi connected to the Internet later - the spare time limit will dictate what happens when.
> 
> And anybody who asks can have a go at controlling them...

By the way, Ledcomm can sync to a bright spotlight, too ! It will be an one directional communication this way, but if the nodes are Ledcomm enabled and if you can quickly modulate a powerful LED spotlight with suitable colour, you can transfer data to all nodes at once. This might help as bus wires and waterproof are difficult to achieve together.

Matthias

[toc] | [prev] | [next] | [standalone]

#40069

On Friday, June 26, 2015 at 10:20:16 AM UTC+1, Matthias Koch wrote:
> JUERGEN schrieb:
> > On Thursday, June 25, 2015 at 2:06:21 PM UTC+1, Matthias Koch wrote:
> >>> Is this clear enough now Matthias?
> >> Thank you for the schematics. How do you implement networking/communication with this setup ? As far as I recall, you wished to make an art or multi-node display installation which would at least require to keep the nodes in sync.
> >>
> >> Matthias
> > 
> > For now we go minimalist here as well:
> > One resistor on RX and the other side all connected. 
> > So just 2 wires to al of them: Ground and RX protected.
> > They get their personal number when programmed the first time. If something goes wrong or the battery is empty - they are off - but do not disturb the rest.
> > Simple but fail safe.
> > More complex will be tried later or if there is time.
> > As said, a 16 unit test panel is ready.
> > 
> > And the plan is to have the systems - or how many might be left after the event,  via Bluetooth or WiFi connected to the Internet later - the spare time limit will dictate what happens when.
> > 
> > And anybody who asks can have a go at controlling them...
> 
> By the way, Ledcomm can sync to a bright spotlight, too ! It will be an one directional communication this way, but if the nodes are Ledcomm enabled and if you can quickly modulate a powerful LED spotlight with suitable colour, you can transfer data to all nodes at once. This might help as bus wires and waterproof are difficult to achieve together.
> 
> Matthias

Have a nice holiday - and you will probably find here what we have achieved in the meantime.
We wil hopefully try the first 16 or 32 Multiprocessor system this weekend.

[toc] | [prev] | [next] | [standalone]

#40071

On Friday, June 26, 2015 at 3:45:46 PM UTC+1, JUERGEN wrote:
> On Friday, June 26, 2015 at 10:20:16 AM UTC+1, Matthias Koch wrote:
> > JUERGEN schrieb:
> > > On Thursday, June 25, 2015 at 2:06:21 PM UTC+1, Matthias Koch wrote:
> > >>> Is this clear enough now Matthias?
> > >> Thank you for the schematics. How do you implement networking/communication with this setup ? As far as I recall, you wished to make an art or multi-node display installation which would at least require to keep the nodes in sync.
> > >>
> > >> Matthias
> > > 
> > > For now we go minimalist here as well:
> > > One resistor on RX and the other side all connected. 
> > > So just 2 wires to al of them: Ground and RX protected.
> > > They get their personal number when programmed the first time. If something goes wrong or the battery is empty - they are off - but do not disturb the rest.
> > > Simple but fail safe.
> > > More complex will be tried later or if there is time.
> > > As said, a 16 unit test panel is ready.
> > > 
> > > And the plan is to have the systems - or how many might be left after the event,  via Bluetooth or WiFi connected to the Internet later - the spare time limit will dictate what happens when.
> > > 
> > > And anybody who asks can have a go at controlling them...
> > 
> > By the way, Ledcomm can sync to a bright spotlight, too ! It will be an one directional communication this way, but if the nodes are Ledcomm enabled and if you can quickly modulate a powerful LED spotlight with suitable colour, you can transfer data to all nodes at once. This might help as bus wires and waterproof are difficult to achieve together.
> > 
> > Matthias
> 
> Have a nice holiday - and you will probably find here what we have achieved in the meantime.
> We wil hopefully try the first 16 or 32 Multiprocessor system this weekend.

Forth INC and GreenArrays have been convinced to support this project as well. Thank you very much to both of them. As soon as we had time, the updated Prospectus with Forth IC and GreenArrays in it as well will be to see at Forth-ev.de as before. 

So our project with the 1000 scouts is basically wrapped up and finacially secure now.

MPE had been in this projeect from the beginning. The MSP430s will be running VFX LITE on the chip.

[toc] | [prev] | [next] | [standalone]

#40070

Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> By the way, Ledcomm can sync to a bright spotlight, too ! It will be
> an one directional communication this way, but... you can transfer
> data to all nodes at once.

This is really neat.  The one thing disappointing about ledcomm is that
it runs at such low bit rates, like 30 bps according to the ChibiOS
page.  I had thought its mechanism was different and that it used the
LED as a photodiode, capable of very fast detection.  I still wonder if
there's a way to do that.  Photodiodes are normally reverse biased (I
had forgotten or didn't know that earlier) so you'd have to use two or
maybe three IO pins to handle both the forward and reverse modes:

  pin o----resistor---o(pin)o----led||resistor----o pin

with another resistor across the led, making a voltage divider with the
first resistor.  The first and third pins would be digital so you could
forward or reverse bias the led by toggling them.  The middle pin is an
analog input that would detect when the led is generating some current,
by measuring the voltage change.  I have no idea whether this would be
sensitive enough though.

I know Forrest Mims wrote a lot of old stuff about using leds as
photodetectors.  I'm not sure if it was similar to ledcomm, or worked
some other way.

[toc] | [prev] | [next] | [standalone]

#40076

On Friday, June 26, 2015 at 3:51:12 PM UTC+1, Paul Rubin wrote:
> Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> > By the way, Ledcomm can sync to a bright spotlight, too ! It will be
> > an one directional communication this way, but... you can transfer
> > data to all nodes at once.
> 
> This is really neat.  The one thing disappointing about ledcomm is that
> it runs at such low bit rates, like 30 bps according to the ChibiOS
> page.  I had thought its mechanism was different and that it used the
> LED as a photodiode, capable of very fast detection.  I still wonder if
> there's a way to do that.  Photodiodes are normally reverse biased (I
> had forgotten or didn't know that earlier) so you'd have to use two or
> maybe three IO pins to handle both the forward and reverse modes:
> 
>   pin o----resistor---o(pin)o----led||resistor----o pin
> 
> with another resistor across the led, making a voltage divider with the
> first resistor.  The first and third pins would be digital so you could
> forward or reverse bias the led by toggling them.  The middle pin is an
> analog input that would detect when the led is generating some current,
> by measuring the voltage change.  I have no idea whether this would be
> sensitive enough though.
> 
> I know Forrest Mims wrote a lot of old stuff about using leds as
> photodetectors.  I'm not sure if it was similar to ledcomm, or worked
> some other way.

Paul, thanks for the input. Please send your High Speed implementation and as well a description of the HW and SW to achieve it. 
That will be brilliant at the event. 
Swap SW quickly.

[toc] | [prev] | [next] | [standalone]

#40077

JUERGEN <epldfpga@aol.com> writes:
> Paul, thanks for the input. Please send your High Speed implementation
> and as well a description of the HW and SW to achieve it.
> That will be brilliant at the event.  Swap SW quickly.

Sorry, I'm just the idea man.

[toc] | [prev] | [next] | [standalone]

#40078

On Friday, June 26, 2015 at 9:10:36 PM UTC+1, JUERGEN wrote:
> On Friday, June 26, 2015 at 3:51:12 PM UTC+1, Paul Rubin wrote:
> > Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> > > By the way, Ledcomm can sync to a bright spotlight, too ! It will be
> > > an one directional communication this way, but... you can transfer
> > > data to all nodes at once.
> > 
> > This is really neat.  The one thing disappointing about ledcomm is that
> > it runs at such low bit rates, like 30 bps according to the ChibiOS
> > page.  I had thought its mechanism was different and that it used the
> > LED as a photodiode, capable of very fast detection.  I still wonder if
> > there's a way to do that.  Photodiodes are normally reverse biased (I
> > had forgotten or didn't know that earlier) so you'd have to use two or
> > maybe three IO pins to handle both the forward and reverse modes:
> > 
> >   pin o----resistor---o(pin)o----led||resistor----o pin
> > 
> > with another resistor across the led, making a voltage divider with the
> > first resistor.  The first and third pins would be digital so you could
> > forward or reverse bias the led by toggling them.  The middle pin is an
> > analog input that would detect when the led is generating some current,
> > by measuring the voltage change.  I have no idea whether this would be
> > sensitive enough though.
> > 
> > I know Forrest Mims wrote a lot of old stuff about using leds as
> > photodetectors.  I'm not sure if it was similar to ledcomm, or worked
> > some other way.
> 
> Paul, thanks for the input. Please send your High Speed implementation and as well a description of the HW and SW to achieve it. 
> That will be brilliant at the event. 
> Swap SW quickly.

Including now Forth and GreenArrays - Anybody who wants to see the latest status of the supporters of this scouts project, see www.forth-ev.de and click on the sublines with the links to the PDFs

[toc] | [prev] | [next] | [standalone]

#40704

On Friday, June 26, 2015 at 10:54:48 PM UTC+1, JUERGEN wrote:
> On Friday, June 26, 2015 at 9:10:36 PM UTC+1, JUERGEN wrote:
> > On Friday, June 26, 2015 at 3:51:12 PM UTC+1, Paul Rubin wrote:
> > > Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> > > > By the way, Ledcomm can sync to a bright spotlight, too ! It will be
> > > > an one directional communication this way, but... you can transfer
> > > > data to all nodes at once.
> > > 
> > > This is really neat.  The one thing disappointing about ledcomm is that
> > > it runs at such low bit rates, like 30 bps according to the ChibiOS
> > > page.  I had thought its mechanism was different and that it used the
> > > LED as a photodiode, capable of very fast detection.  I still wonder if
> > > there's a way to do that.  Photodiodes are normally reverse biased (I
> > > had forgotten or didn't know that earlier) so you'd have to use two or
> > > maybe three IO pins to handle both the forward and reverse modes:
> > > 
> > >   pin o----resistor---o(pin)o----led||resistor----o pin
> > > 
> > > with another resistor across the led, making a voltage divider with the
> > > first resistor.  The first and third pins would be digital so you could
> > > forward or reverse bias the led by toggling them.  The middle pin is an
> > > analog input that would detect when the led is generating some current,
> > > by measuring the voltage change.  I have no idea whether this would be
> > > sensitive enough though.
> > > 
> > > I know Forrest Mims wrote a lot of old stuff about using leds as
> > > photodetectors.  I'm not sure if it was similar to ledcomm, or worked
> > > some other way.
> > 
> > Paul, thanks for the input. Please send your High Speed implementation and as well a description of the HW and SW to achieve it. 
> > That will be brilliant at the event. 
> > Swap SW quickly.
> 
> Including now Forth and GreenArrays - Anybody who wants to see the latest status of the supporters of this scouts project, see www.forth-ev.de and click on the sublines with the links to the PDFs

We are one week away from the event - all parts have been donated ( except for the TicTac boxes ) so the 1024 scouts can start soldering soon and will own their "beating Heart". A 16 processor cluster has been tested - so high hopes to get the 1024 multiprocessor cluster up and running - 1024 MicroBoxes with batteries connected and controlled centrally to light up as 32 x 32 bit LED Array - no it is not a giant torch, we only have about 10mA per LED. 
A 16 bit cluseter has been tested as proof of concept.
See as well other post about Cloning an MSP430 for programming.

[toc] | [prev] | [next] | [standalone]

#40718

JUERGEN <epldfpga@aol.com> writes:
> We are one week away from the event - all parts have been donated (
> except for the TicTac boxes ) so the 1024 scouts can start soldering

The TicTac boxes sound like the hardest part--you can't even buy empty
ones as far as I know.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web