Nodes not always connecting

First: Big thanks for the Jumperless, what a great project!

I may be doing something wrong here, but using pyserial to make vertical connections from pin 1 to 31, 2 to 32 … etc (on a Jumperless with firmware v1.1.1.1.5 from 2023-12-31), it seems that nodes are not always being bridged.

Here’s the code I use:

#!/usr/bin/env python3
from serial import Serial

with Serial(port="/dev/ttyACM1", baudrate=57_600, timeout=1.0) as jumperless:
    jumperless.write(b"::bridgelist[1-31,2-32,3-33]\n")
    while line := jumperless.readline():
        print(line.decode().strip())

Here’s the output of this script:

❯ ./jltest.py


opened nodeFile.txt

loading bridges from file


opened nodeFile.txt

loading bridges from file


raw input file

[1-31,2-32,3-33,]

splitting and cleaning up string

_
[1-31,2-32,3-33,]
^

replacing special function names with defined ints

[1-31,2-32,3-33,]
replacing special function names with defined ints

[1-31,2-32,3-33,]



parsing bridges into array

node1 = 1
node2 = 31
readLength = 5
specialFunctionsString.length() = 17
1-0
node1 = 2
node2 = 32
readLength = 10
specialFunctionsString.length() = 17
2-0
node1 = 3
node2 = 33
readLength = 15
specialFunctionsString.length() = 17
3-0
node1 = 0
node2 = 0
[1-31],[2-32],[3-33],
bridge pairs = 3
::ok



Menu

n = show netlist
b = show bridge array
w = waveGen
v = toggle show current/voltage
f = load formatted nodeFile
u = set baud rate for USB-Serial
l = LED brightness / test
d = toggle debug flags
r = reset Arduino

After running the script, the Jumperless reports the following netlist:

Index	Name		Number	Color		Nodes
0	Empty Net	127	0x0		EMPTY_NET		{0-0}
1	GND		1	0x1C04		GND			{0-0}
2	+5V		2	0x1C0702	5V			{0-0}
3	+3.3V		3	0x1C0107	3V3			{0-0}
4	DAC 0		4	0x231111	DAC_0			{0-0}
5	DAC 1		5	0x230913	DAC_1			{0-0}
6	I Sense +	6	0x232323	I_POS			{0-0}
7	I Sense -	7	0x232323	I_NEG			{0-0}

Index	Name		Number	Color		Nodes
8	Net 8		8	0x1F2000	1,31			{1-31}
9	Net 9		9	0x200C		2,32			{2-32}
10	Net 10		10	0x1720		3,33			{3-33}

LEDs light up as I assume is intended: 3 different colors, one for each of the pairs (1,31), (2,32) and (3,33)

But: Using a DMM shows that only (1,31) and (2,32) are connected; (3,33) remains open.

If i send ::bridgelist[3-33,4-34,5-35], LEDs & netlist reflect the bridges I sent:

Index	Name		Number	Color		Nodes
8	Net 8		8	0x1F2000	3,33			{3-33}
9	Net 9		9	0x200C		4,34			{4-34}
10	Net 10		10	0x1720		5,35			{5-35}

while this time I measure only (3,33) as being connected, the other two remain open.

Sending all 30 vertical connections lights up all the LEDs, netlist looks OK, but only the vertical connections featuring pins
1, 2, 9, 16, 23 are actually being made.

I haven’t done any other tests, but based on what I wrote, maybe someone can point me into the right direction to figure this out …

1 Like

Hey Bernhard,

I tried it on mine and yes, that’s a routing bug in the code, kinda surprising I missed that one. It’s a part of the code I was messing with recently so I must have missed something dumb.

Sorry about that, I’ll push a fix for that ASAP and let you know.

1 Like

Hey, try this firmware and let me know what happens. I’m gonna go through it and add a couple more tricks to allow it to connect even more worst-case netlists before I call it a new release. But for now, this should work well.

firmware.uf2 (398 KB)

Thanks for the quick reply & preliminary firmware!

It looks like not everything is ironed out yet: after flashing the attached firmware, sending a list of all vertical connections like so

bridges = ",".join(f"{i}-{i+30}" for i in range(1, 31))
jumperless.write(f"::bridgelist[{bridges}]\n".encode())

leads to some weird results:

  • some connections are still missing (e.g. the vertical connections featuring pins 24 up to 29, also others)
  • there’s at least one connection where there should be none (19, 48)
  • (I assume this has to do with how many internal switches are involved, but I’ll mention it for completness’ sake) some of the connections have a resistance of around ~80 Ohms (1,31) while others measure around ~170 Ohms (3,33)

Hope this helps with debugging.

Yeah, connecting all the vertical rows is the absolute worst case scenario for routing.

It’s not a “fully connected” crosspoint matrix (that would require ~60 crosspoint chips) so it needs to find alternative paths for connections until it eventually just runs out of possible places to go and just can’t make any more connections. Most realistic circuits, even if they’re pretty dense should be fine.

When you’re reading 180 ohms, that means it had to go through a second crosspoint switch to get there.

If you turn on the debug flags, it will show you more about what’s going on.

thanks for the explanation!

I was planning to use the Jumperless as a router for audio signals to dynamically connect synthesizers and effects pedals in different ways (a little bit like this, only less ambitious).

If everything’s connected, that would be around 25 connections - would this be a viable use case for the Jumperless or am I running the risk of running out of crosspoint switches? (Vertical connections are not important for this, it just seemed an obvious way to connect things).

Ha, that’s actually a roadmapped thing to make it work as an Erica Synths Matrix mixer. But I don’t do synth stuff myself so I’m really glad you’re working on it because you’d know better how you’d like it to work.

And yes, it can totally handle 25 connections, it’s just the switches directly across the breadboard have only 1 direct connection between them to make room for the special function chips.

Another tip for maximizing the number of connections is to kinda spread them out a much as possible to not force one chip to do all the connecting while the rest are empty.

Let me know if you run into any problems and you should totally post your progress somewhere because I really want to see it

Thanks, that’s really helpful!

Don’t expect too much from my efforts, but what I come up with, I’ll gladly share.

1 Like

Awesome, there’s a new firmware!

Understanding that vertical connections are a worst-case thing, I decided to keep left side stereo channels on pins 1-30 and right side stereo channels on pins 31-60. Since I won’t be connecting left-to right or vice versa I assume this will make routing easier.

Two ideas crossed my mind:

  • if it’s easy to determine whether switches are maxed out (or if there’s any other kind of routing trouble) it might be helpful if there were a visual indicator for this (blinking jumperless LED?) - especially when there’s connections being made that weren’t specified
  • (not having read the docs on routing) maybe it would be interesting to have different routing algorithms available, e.g. maximizing number of connections vs. keeping number of hops constant for constant bridge resistance

(I know that there’s more important things to implement)

1 Like

Sadly, I’m still getting routing issues, even with as little as 3 bridges (that don’t cross top/bottom boundaries):

When I send a bridgelist containing only the 3 bridges
(1,2), (5,6) and (9,10), bridges (1,2) and (9,10) end up being connected, even though they shouldn’t be.

Ah I found the issue there, I took out the part that was checking the other side for freeness when picking a random node to bounce off of, here’s the fixed firmware.
firmware.uf2 (399.5 KB)

That’s actually a great idea. A lot of these issues are from me starting to rewrite the routing code in a less impossible-to-understand-unless-you-wrote-it way. Which should hopefully allow for much easier tweaks to the algorithm, so thanks for the idea.

That’s the next thing I’m adding, now that Jumperlab is fairly useable, I can send a response with any issues encountered during routing and the GUI can tell you what went wrong.

1 Like

Ah I found the issue there, I took out the part that was checking the other side for freeness when picking a random node to bounce off of, here’s the fixed firmware.

Thanks, this one looks promising!

That’s great by the way! And keeping with the brainstorming: what would you think about separate PREPARE and COMMIT commands for bridgelists? Potential problems could be reported at the prepare stage, therefore keeping sensitive electronics safe before a potentially troublesome circuit gets committed (if that’s an actual risk for future firmware versions - I understand that my previous troubles were fixed by the current firmware)