How to tell an IP address with 4 LEDs? - hardware

I am developing a net-managed device with the .NET Micro Framework. Since the idea is to have a bunch of devices in an office, sometimes it is necessary for the user to know the IP address of a specific device.
So I've been trying to come with ideas on how to indicate the IP address the user. The only user interface is 4 LED lights that I can blink on and off at varying speeds.
So far, the best idea I could come up with is this: seeing how the IP address has 4 parts and I have 4 LEDs, it would make sense that each LED be responsible for a single IP address part.
So for address like 192.168.0.34, I'd have LED1 blink once, then pause, then blink 9 times, pause, then blink 2 times. The action would then shift to the LED2, which would blink out 168 in a similar manner and so on. Number 0 would be indicated by blinking really fast for half a second.
Any other ideas?

Use all 4 displays at once for each number, showing it in binary. Blink all 4 really fast for a 0, light all 4 longer to denote a point.
[ ] [ ] [ ] [x] # 1
[x] [ ] [ ] [x] # 9
[ ] [ ] [x] [ ] # 2
[x] [x] [x] [x] # . (long)
[ ] [ ] [ ] [x] # 1
[ ] [x] [x] [ ] # 6
[x] [ ] [ ] [ ] # 8
[x] [x] [x] [x] # . (long)
[x] [x] [x] [x] # 0 (short)
Alternatively you can use an un-used number (ie: 10) to denote 0
[ ] [ ] [ ] [x] # 1
[x] [ ] [ ] [x] # 9
[ ] [ ] [x] [ ] # 2
[x] [x] [x] [x] # .
[ ] [ ] [ ] [x] # 1
[ ] [x] [x] [ ] # 6
[x] [ ] [ ] [ ] # 8
[x] [x] [x] [x] # .
[x] [ ] [x] [ ] # 0
Having a lookup table ready by the device should be enough for those who don't know binary.

I'd do the reverse. From a control station, I would bring up a list of all IPs used by my devices. I'd then select one to start blinking in a pattern that would be easy to recognize (like 1 2 3 4 over and over) until shut off. That way I could ask everybody who's LEDs are blinking like that and know what device owned that IP.
I'd then write the IP on the bottom of the device in magic marker. There's an amazing amount of bandwidth in a sharpie.

Provide a well-mounted cord for the user to swing the device around in the air like a lasso
Then flash the LEDs like a propeller clock
(source: embedds.com)

You might also consider binary, displaying a single digit at a time. But this would require the user to know (or take a crash course on) binary.
9: 1 0 0 1
8: 1 0 0 0
7: 0 1 1 1
6: 0 1 1 0
5: 0 1 0 1
4: 0 1 0 0
3: 0 0 1 1
2: 0 0 1 0
1: 0 0 0 1
0: 0 0 0 0
To indicate the decimal point, you could show 1 1 1 1. It would be ideal if you had a button or some form of user interaction so that you could iterate through the digits.

You could translate the number to HEX and print off the hex representation in binary.
F: 1 1 1 1
E: 1 1 1 0
D: 1 1 0 1
C: 1 1 0 0
B: 1 0 1 1
A: 1 0 1 0
9: 1 0 0 1
8: 1 0 0 0
7: 0 1 1 1
6: 0 1 1 0
5: 0 1 0 1
4: 0 1 0 0
3: 0 0 1 1
2: 0 0 1 0
1: 0 0 0 1
0: 0 0 0 0
192.168.0.34 becomes C0.A8.00.22. Very similar to the solution put forth by #JYelton, just taken a step further to reduce the amount of work an individual needs to do to read the message out of the LEDs. Still require a bit of translation though because you have to go from hex to decimal again (standard calculator is an easy/handy tool).

I'm thinking outside the box.. but one of the biggest complaints I see here is the translation. What about an app that takes a video (recording or prerecorded) and does the interpretation? This reminds me of iphone apps that can read upc codes.
Alternatively, but along the same thought, what about a parallel port or usb?

Why don't you get an external LCD screen... no teaching users binary and you can display loads more information. If you provide me with which micro framework device you are using I may be able to provide more detailed help.
LCDs - SparkFun <= good products and service
LCDs - Jameco
LCDs - Mouser

Could do it the way that the pulse dialing worked in the phone system. Basically one blink is zero, and it counts up from there.
1 = ** (2 blinks)
9 = ********** (10 blinks)
2 = *** (3 blinks)
Long Blink
1 = ** (2 blinks)
6 = ******* (7 blinks)
8 = ********* (9 blinks)
Long Blink
0 = * (1 blink)
0 = * (1 blink)
1 = ** (2 blinks)
Long Blink
2 = *** (3 blinks)
4 = ***** (5 blinks)
1 = ** (2 blinks)

Depending on how geeky your users are, you could also use:
Morse code
Display IP as a sequence of digits in binary
...

if it's DHCP, and they can access a list of the devices ip addresses on a computer next to the devices' MAC addresses, you could write the MAC address on each device and then they'd be able to tell which device had which IP.
If you think MAC addresses would be too un user friendly then you could have a table of the MAC addresses with a short description or the name of the devices.
Even more, you could write a program that got the list of ip addresses next to MAC addresses and matched it up with the table of device names next to MAC addresses.

If you replace one of the leds with an IR led, you can write an app for a cell phone IR sensor that decodes and displays the binary pattern for the IP address.

What about Broadcasting UDP packets and using a winforms app to listen for those packets. If you have multiple of these devices, the following might work.
Open Windows Client that is listening on the correct port.
Reset device or push a button on it to activate the UDP Broadcast.
Maybe combine the LED's flashing actively on that unit for 1 minute.
The Windows Client would then receive the IP Address and any other status information.
There may be an option here to set a unique ID (1-16 binary) in the device that is displayed on the device and broadcast with the IP Information. (??DIP Switches??)
This gets away from having users interpreting binary flashing of the LED's.
So device 1010 shows it's LED's and the output in the Windows App shows
On, Off, On, Off = 192.168.0.150
If you got fancy with this using Images of an LED On and Off would be even better.
I'm in a similar situation and haven't tested these theories yet.

Well, does the IP address need to be interpreted by a machine or by a human? Because your suggestion is using decimal digits, which is wonderful for humans but very complicated for computers to understand.
IP addresses are actually just a 32-bit binary number. The IP 192.168.0.34 is seen by the router (and broadcasted across the internet) as 11000000 10101000 00000000 00100010
If you're having a computer or other hardware device interpret the IP address, I suggest just using binary. You could have one light which displays the next digit, and another which toggles a "ready" light to indicate that the digit is in fact the next one and not a repetition of the previous one. This would only require 2 LEDs, and you would essentially display the aforementioned address like so:
on on,
on off,
off on,
off off,
off on,
off off,
off on,
off off,
on on,
off off,
on on,
off off,
on on,
off off,
off on,
off off,
etc.
Make sure the second bit has toggled before reading the first bit, otherwise you could read the same number twice.
If you want to display it using four LEDs for human interpretation then having the LEDs blinks according to digit might be difficult since humans have trouble counting 4 numbers simultaneously. It may be easier if you just went through all the digits 1, 9, 2, 1, 6, 8, 0, 0, 0, 0, 3, 4 (3 digits per number) and displayed these in binary using all four LEDs.
off off off on,
on off off on,
off off on off,
etc.
With a pause in between each one.

Adding an LCD display would work really well, but would add a lot to the cost. However, what about using 8 LEDs instead of 4? If you purchase the 8 LEDs in the form of a 7-segment LED display with decimal point, it might not cost much more than 4 discrete LEDs, but it would let you display the decimal digits of the IP address sequentially. No complicated translation scheme for the users to master.

It depends on your environment, but I'd not display an entire IP address, just the component that is relevant, and map that itself to a single 4-bit number. This assumes you only need to uniquely identify < 2^4 entities. If you need more, then just use more LEDs (if possible).
In this way, you'd only need to indicate a local mapping, which could then be used to look the actual IP address up via a local internal website. You can use the typical binary strategy that's been described in this thread already to have the LEDs flash out a 4bit number, and it should be pretty easy to train people on (which appropriate labeling on the device).

Related

How do I feed CD audio tracks into an ALSA-driven sound output device?

I'm using a USB CD/DVD drive without built-in sound decoder and controlling it via ALSA, which already works. The host is a Raspberry Pi 3B with the current Raspbian. Here is the corresponding config file:
pi#autoradio:/etc $ cat asound.conf
pcm.dmixer {
type dmix
ipc_key 1024
ipc_perm 0666
slave {
pcm "hw:0,0"
period_time 0
period_size 1024
buffer_size 4096
rate 192000
format S32_LE
channels 2
}
bindings {
0 0
1 1
}
}
pcm.dsnooper {
type dsnoop
ipc_key 2048
ipc_perm 0666
slave
{
pcm "hw:0,0"
period_time 0
period_size 1024
buffer_size 4096
rate 192000
format S32_LE
channels 2
}
bindings {
0 0
1 1
}
}
pcm.duplex {
type asym
playback.pcm "dmixer"
capture.pcm "dsnooper"
}
pcm.!default {
type plug
slave.pcm "duplex"
}
ctl.!default {
type hw
card 0
}
To read the music from CD-DA, I'm gonna use the CDIO++ library. Its cd-info utility recognises both the drive, and the audio CD:
pi#autoradio:/etc $ cd-info
cd-info version 2.1.0 armv7l-unknown-linux-gnueabihf
CD location : /dev/cdrom
CD driver name: GNU/Linux
access mode: IOCTL
Vendor : MATSHITA
Model : CD-RW CW-8124
Revision : DA0D
Hardware : CD-ROM or DVD
Can eject : Yes
Can close tray : Yes
Can disable manual eject : Yes
Can select juke-box disc : No
Can set drive speed : No
Can read multiple sessions (e.g. PhotoCD) : Yes
Can hard reset device : Yes
Reading....
Can read Mode 2 Form 1 : Yes
Can read Mode 2 Form 2 : Yes
Can read (S)VCD (i.e. Mode 2 Form 1/2) : Yes
Can read C2 Errors : Yes
Can read IRSC : Yes
Can read Media Channel Number (or UPC) : Yes
Can play audio : Yes
Can read CD-DA : Yes
Can read CD-R : Yes
Can read CD-RW : Yes
Can read DVD-ROM : Yes
Writing....
Can write CD-RW : Yes
Can write DVD-R : No
Can write DVD-RAM : No
Can write DVD-RW : No
Can write DVD+RW : No
__________________________________
Disc mode is listed as: CD-DA
I've already got some code to send the PCM data to the sound card and some insight regarding the (rather poorly documented) CDIO API (I know that the readSectors() method is used for reading sound data from the CD sector after sector), but not really a clue on how to hand over the data from the CD-DA input to the ALSA output routine correctly.
Please nopte that mplayer is off-limits to me as this routine will be a part of a larger solution.
Any help would be greatly appreciated.
UPDATE: Does the different block size of an audio CD (2,352 bytes) and of the sound output (910 bytes, at least in my particular case) matter?
CD audio data is just two channels of little-endian 16-bit samples at 44.1 kHz.
If you output the data to the standard output, you can pipe it into your sound-playing program, or aplay:
./my-read-cdda | ./play 44100 2 99999
./my-read-cdda | aplay --file-type raw --format cd
If you want to do everything in a single program, replace the read(0, ...) with readSectors(). (The buffer size does not need to have any relation with ALSA's period size or buffer size.)

How to match job id to a rule shell script

I just finished my bowtie2 alignment jobs by snakemake.
But as you know, bowtie2 output a align summary:
23774776 reads; of these:
23774776 (100.00%) were paired; of these:
5928889 (24.94%) aligned concordantly 0 times
17845887 (75.06%) aligned concordantly exactly 1 time
0 (0.00%) aligned concordantly >1 times
----
5928889 pairs aligned concordantly 0 times; of these:
1214536 (20.49%) aligned discordantly 1 time
----
4714353 pairs aligned 0 times concordantly or discordantly; of these:
9428706 mates make up the pairs; of these:
6563535 (69.61%) aligned 0 times
2843810 (30.16%) aligned exactly 1 time
21361 (0.23%) aligned >1 times
86.20% overall alignment rate
This summary was wroten in the following files:
snakejob.align.601.sh.e6589895
snakejob.align.602.sh.e6591632
snakejob.align.603.sh.e6591988
snakejob.align.604.sh.e6591623
snakejob.align.605.sh.e6591927
snakejob.align.606.sh.e6591628
snakejob.align.607.sh.e6590473
snakejob.align.608.sh.e6591280
snakejob.align.609.sh.e6590190
snakejob.align.610.sh.e6590903
There was no sample name in the summary. I think the snakejob id (6**) may hava a relationship with the sample name.
I have checked the files in the hidden folder .snakemake/metadata, the message in the file looks like:
{"rule": "PE", "shellcmd": "/soft/samtools/samtools view -bF 12 /home/RAD/01align/out/R40.bam > /home/RAD/01align/out/R40.PE.bam && echo '3 done'", "params": [], "version": null, "incomplete": false, "input": ["/home/RAD/01align/out/R40.bam"], "code": "gAMoQxR0AABkAQBkAgB8CgCDAQEBZAAAU3EAKFgFAAAAaW5wdXRxAVgGAAAAb3V0cHV0cQJYBgAAAHBhcmFtc3EDWAkAAAB3aWxkY2FyZHNxBFgHAAAAdGhyZWFkc3EFWAkAAAByZXNvdXJjZXNxBlgDAAAAbG9ncQdYBwAAAHZlcnNpb25xCFgEAAAAcnVsZXEJWAkAAABjb25kYV9lbnZxClgMAAAAYmVuY2hfcmVjb3JkcQt0cQxdcQ0oTlhYAAAAL25mcy9iaW9zb2Z0L3NhbXRvb2xzL3NhbXRvb2xzIHZpZXcgLWJGIDEyIHtpbnB1dC5iYW19ID4ge291dHB1dC5QRWJhbX0gJiYgZWNobyAnMyBkb25lJ3EOaAtlWAUAAABzaGVsbHEPhXEQdHERLg==", "log": []}
The code section may contain some help information for me to get the sample name. But I don’t know how to generate these code value.
I hope someone could help me out.
The portable solution to this is to specify a log file for the rule. See the docs. Also have a look at the best practice workflow(s) from the Snakemake workflows project.

How to deduce the side affected by mate evaluatiion

I have a GUI communicating with a uci chess engine (Stockfish 8). The problem is that when the engine finds a mate, it only sends output containing ". . . score mate 1 nodes 4677 . . .". I can deduce this means there is mate in one move (#1). But, unlike cp evaluation, I don't see negative sign when it is Black that can mate. So, how do I know if it is White or Black that can mate?
No. You'll get a negative sign when the player to move gets checkmated. Try it yourself:
position fen 7k/6q1/6q1/8/8/8/8/7K w - -
go infinite
You'll get:
info depth 127 seldepth 3 multipv 1 score mate -1 nodes 273 nps 39000 tbhits 0 time 7 pv h1h2 g7h6
Do you see the "mate -1"? The sign is relative to the player to move in the root position.

Understanding the bitstream generated for iCE40 I/O tiles

When I synthesize an empty circuit using Yosys and arachne-pnr, I get a few irregular bits:
.io_tile 6 17
IoCtrl IE_1
.io_tile 6 0
IoCtrl REN_0
IoCtrl REN_1
These are also part of every other file I could generate so far. Since an unused I/O tile has both IE bits set, I read this as:
for IE/REN block 6 17 0, the input buffer is enabled
for IE/REN block 6 0 0, the input buffer is enabled and the pull-up resistor is disabled
for IE/REN block 6 0 1, the input buffer is enabled and the pull-up resistor is disabled
However, according to the documentation, there is no IE/REN block 6 17 0.
What is the meaning of these bits? If the IE bit of block 6 17 0 is unset because the block doesn't exist, why aren't the bits of the other blocks which don't exist unset, too? The other IE/REN blocks seem to correspond to I/O blocks 6 0 1 and 7 0 0. What do these blocks do, and why are they always configured as inputs?
The technology library entry for SB_IO does not mention the IE bit. How is it related to the PIN_TYPE parameter settings?
When I use an I/O pin as an input, the REN bit is set (the pull-up resistor disabled). This suggests that the pull-up resistors are primarily intended to keep unused pins from floating, not to provide a pull-up resistor for conditionally connected inputs (e.g. buttons). Is this assumption correct? Would it be ok to use the internal pull-up resistors for that purpose?
The technology library says the following:
defparam IO_PIN_INST.PULLUP = 1'b0;
// By default, the IO will have NO pull up.
// This parameter is used only on bank 0, 1,
// and 2. Ignored when it is placed at bank 3
Does this mean bank 3 doesn't have pull-up resistors, or merely that they can't be re-enabled using Verilog? What would happen if I clear that bit in the ASCII bitstream manually? (I'd be trying this, but the iCEstick evaluation board doesn't make any pin on bank 3 accessible – a coincidence? – and I'm not sure if I want to mess with the hardware yet.)
When I use an I/O pin as an output, the IE bit isn't cleared, but the input pin function is set to PIN_INPUT. What effect does this have, and why is it done?
The default behavior for unused IO pins is to enable the pullup resistors and disable input enable. On iCE40 1k chips this means IE_0 and IE_1 are set and REN_0 and REN_1 are cleared in an unused IO tile. (On 8k chips IE_* is active high, i.e. all bits are cleared in an unused IO tile on an 8k chip.)
icebox_explain by default hides tiles that have "uninteresting" contents. (Run icebox_explain -A to disable this feature.)
It looks like arachne-pnr does not set those bits for IO pins that are not available in the current package. Thus you get some unusual bit pattern in some IO tiles that contain IE/REN bits for IO blocks not connected to any package pin.
This is what a "normal" unused IO tile looks like on the 1k architecture:
$ icebox_explain -mAt '1 0' example.asc
Reading file 'example.asc'..
Fabric size (without IO tiles): 12 x 16
.io_tile 1 0
B0 ------------------
B1 ------------------
B2 ------------------
B3 ------------------
B4 ------------------
B5 ------------------
B6 ---+--------------
B7 ------------------
B8 ------------------
B9 ---+--------------
B10 ------------------
B11 ------------------
B12 ------------------
B13 ------------------
B14 ------------------
B15 ------------------
IoCtrl IE_0
IoCtrl IE_1
Would it be ok to use the internal pull-up resistors for that purpose?
Yes.
The technology library entry for SB_IO does not mention the IE bit. How is it related to the PIN_TYPE parameter settings?
When D_IN_0 or D_IN_1 from SB_IO is connected to something, then this implies IE.
When I use an I/O pin as an output, the IE bit isn't cleared
Note that IE is active low on 1k chips and active high on 8k chips. When you use an I/O pin as output-only pin on a 1k device, then the corresponding IE bit should be set, otherwise it should be cleared.
I found the explanation, so I'm sharing it here for future reference:
.io_tile 6 17
IoCtrl IE_1
I/O block 16 7 0 is connected to a pin in some packages but not in the TQFP package.
.io_tile 6 0
IoCtrl REN_0
IoCtrl REN_1
This corresponds to I/O blocks 6 0 1 and 7 0 0 (pins 49 and 50) into whose input paths the PLL PORTA and PORTB clocks are fed, respectively.

LVS: All connections are InActConn

All connections are InActConn
I'm a newbie using LVS. I've tried LVS/TUN and LVS/DR, the result is the same, all connections are InActConn. But the realservers can be reach (through PING). Pls help!!!
OS: CentOS 6.2
RemoteAddress:Port Forward Weight ActiveConn InActConn
UDP 192.168.10.240:2345 rr
-> 192.168.10.251:2345 Tunnel 1 0 10
-> 192.168.10.252:2345 Tunnel 1 0 9
-> 192.168.10.253:2345 Tunnel 1 0 9
This is the expected behavior for services not maintaining connections, like UDP. You may want to read the LVS Howto, especially the part about Active/Inactive connections :
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.ipvsadm.html#ActiveConn
Old Question : But I got to this post from Google and want to paste my findings here.
In the above answer, the link pasted by #remi-ggacogne missed 1 step for Real server.
You have to turn rp_filter off (esp. in Centos / RHEL ) https://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filtering
Open /etc/sysctl.conf and paste below lines ( as per your network interface )
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.tunl0.rp_filter = 0
To make the above active -->
$systcl -p