I think the original code that @JonnyMac wrote was 128 bytes (4 lines, 32 characters each) per record. Therefore 256. Maybe minus a few for other configuration bits.
Seems limiting and fairly basic too..
I just revisited i2c vs SPI flash, and the price trends are interesting.
i2c is pushed more into niche pricing, and a 128kB i2c part, is not just slightly more than 64k, but close to 2x.
Meanwhile SPI FLASH continues to fall, and I see
4 Mbit = 0.23848 @ qty 1,000
1 MBit = 0.21820 @ qty 1,000
That starts to look like a flip back to 32k i2c, with a SPI Flash makes more sense ?
Badges are hackable so hack away, but I think this is starting to get off topic. While making hardware changes to increase functionality is interesting we really should be focused on programming attendee info and reading back badge contacts based on the hardware we have.
I think the original code that @JonnyMac wrote was 128 bytes (4 lines, 32 characters each) per record. Therefore 256. Maybe minus a few for other configuration bits.
Seems limiting and fairly basic too..
I just revisited i2c vs SPI flash, and the price trends are interesting.
i2c is pushed more into niche pricing, and a 128kB i2c part, is not just slightly more than 64k, but close to 2x.
Meanwhile SPI FLASH continues to fall, and I see
4 Mbit = 0.23848 @ qty 1,000
1 MBit = 0.21820 @ qty 1,000
That starts to look like a flip back to 32k i2c, with a SPI Flash makes more sense ?
Yes, that would be nice. It would also allow some of the SPI flash to be used to run larger PropGCC programs using the XMM memory model. In fact, with a small boot loader, you could use an even smaller EEPROM and boot the real image from SPI flash.
That starts to look like a flip back to 32k i2c, with a SPI Flash makes more sense ?
Badges are hackable so hack away, but I think this is starting to get off topic. While making hardware changes to increase functionality is interesting we really should be focused on programming attendee info and reading back badge contacts based on the hardware we have.
Already covered in my earlier post, including a link to existing hardware and drivers you can use.
However, it is clear there are many limits and compromises with the present badge, (Storage is very low for a graphics display, Link bandwidth is very low for data flow )
When designing new software, only the truly blinkered would not also consider what the next badge might look like.
A web-based app can probably be written in Javascript if it is possible to access a serial port from JS which I believe it is.
Javascript does not have direct access to serial ports. However, it can interact with a locally-running server program that provides that access indirectly. That's how my SpinScope program operates.
There's what appears to be a server/client combo based upon node.js here:
A web-based app can probably be written in Javascript if it is possible to access a serial port from JS which I believe it is.
Javascript does not have direct access to serial ports. However, it can interact with a locally-running server program that provides that access indirectly. That's how my SpinScope program operates.
There's what appears to be a server/client combo based upon node.js here:
At the moment my ideas are purely hypothetical since I don't have a badge to play with. What IR tranceiver is used on the badge? I'm wondering if I have the parts around to simulate one. Is it the same as the DefCon 22 badge?
...... I was wondering what it would take to create a "connector" or stand-alone programmer (as @jmg suggested) that you would just temporarily press into prototyping vias. This would have potential applications for the above conversation, but it would also allow another interesting idea: plug-in badge extensions. For instance, if a conference badge needs more storage, provide an upgrade board that would press-fit into the badge. If you want to add a low-profile d-pad, provide an upgrade board that would press-fit into the badge. I'm sure you get the gist...
Plug-in badge extensions is more challenging, but there are connection choices.
The BBC design uses larger plated holes designed for 4mm banana plugs, and edge connectors, or plated edge-holes are another way to make programming connections.
We have used clothes-peg type spring+clamp connections into holes for pgm.
Could work with a clam-shell fixture for Master-Slave faster updates. (connector goes on master only, slave has very low cost, gold plated holes at the dome locations, with maybe a SMD part carefully placed to the notch, to give XY registration...)
What IR tranceiver is used on the badge? I'm wondering if I have the parts around to simulate one. Is it the same as the DefCon 22 badge?
Yes.
Excellent! I have a DefCon 22 badge and I also cobbled together an I/R interface that would talk to it from back when I ported JonnyMac's DefCon 22 badge code to C++. Do you happen to know if the DefCon badge also has a 64k EEPROM?
What IR tranceiver is used on the badge? I'm wondering if I have the parts around to simulate one. Is it the same as the DefCon 22 badge?
Yes.
Excellent! I have a DefCon 22 badge and I also cobbled together an I/R interface that would talk to it from back when I ported JonnyMac's DefCon 22 badge code to C++. Do you happen to know if the DefCon badge also has a 64k EEPROM?
A web-based app can probably be written in Javascript if it is possible to access a serial port from JS which I believe it is.
Javascript does not have direct access to serial ports. However, it can interact with a locally-running server program that provides that access indirectly. That's how my SpinScope program operates.
There's what appears to be a server/client combo based upon node.js here:
At the moment my ideas are purely hypothetical since I don't have a badge to play with. What IR tranceiver is used on the badge? I'm wondering if I have the parts around to simulate one. Is it the same as the DefCon 22 badge?
The IR parts may be a little different but both badges run 36Khz.
The IR parts may be a little different but both badges run 36Khz.
I busted out some IR parts from my Prop Education Kit and plan to mock something up with the badges I have. If I can get them talking I will go further.
The IR parts may be a little different but both badges run 36Khz.
I busted out some IR parts from my Prop Education Kit and plan to mock something up with the badges I have. If I can get them talking I will go further.
Be aware the PEK parts are 38Khz and may not talk to either badge, (36 Khz).
Be aware the PEK parts are 38Khz and may not talk to either badge, (36 Khz).
It's not optimal, but a Vishay spec shows a 38kHz device is at ~40% sensitivity for +/-10% skew & +/- 5% looks > 70%
ie range will be down a little, but testing should be ok.
I've been thinking of this problem since Ken and Seairth tweeted about how they were getting those badges ready. Most of all I thought of the problem of programming so many badges.
As far as I can see, there were two main problems:
Each of the badges had to be personalized, by modifying the program, recompiling and then downloading to a "virgin" badge
Because the serial connection works with an FTDI chip, Windows creates a new COM port for every board.
Both of these are very time-intensive, so it probably took maybe 10 minutes to program each board. That is unacceptable.
We're already discussing the possibilities of modifying the badge software so that it has a way to somehow change the owner's information in the same fashion as how a PC BIOS and Windows let you interrupt it while booting, to change settings. I've been thinking of how a program (which is now identical for each badge) can be downloaded to many badges (or other products) in quick succession.
I was thinking: It shouldn't be too hard to create a jig that lets you mount a board: basically just drop it in and twist a clamp or something to hold it down for programming. You can connect a number of those jigs to a device (let's call it the "Proplicator"), and make it run a program that downloads the badge software into the EEPROMs on the badges.
Each jig would connect to the badges via 5 pogo pins: VDD, VSS, RESn, SDA and SCL. The Proplicator pulls RESn LOW so that the badge Propeller doesn't start. The Proplicator can detect the presence of a badge because SDA and SCL have pull-up resistors (the Proplicator hardware should have some very weak pull-down resistors to pull SDA and SCL down when nothing is "jigged up). As soon as the Proplicator detects a board, it can use I2C to download the program to the badge's EEPROM. When done, it releases SDA and SCL and makes RESn high. That starts the Propeller on the badge using its own (now programmed) EEPROM. The program on the badge will make the display and LEDs work so the user knows that the board was programmed correctly and can take it out to replace it with another badge. With seven jigs working in tandem, this could go REALLY fast, you could probably get the handling time per board reduced from several minutes to several seconds.
I thought of what the most useful way would be to implement a Proplicator (hardware and software), and I think the best way would be this:
Each jig is connected to the Proplicator via 4 data pins (plus two power pins). The data pins are connected to SDA, SCL, RESn of the board that's being jigged, plus a spare pin. The spare pin can be used e.g. for an LED on the jig that shows that the EEPROM was programmed correctly or to indicate that there's a problem (I have some other possibilities in mind too). This adds up to 28 pins which leaves 4 pins on the Proplicator's Propeller chip for serial port and EEPROM.
The Proplicator software runs 7 instances of a program (one per cog) that detects a jigged-up board on its own 4-pin pin-group, and when it detects a board, it programs it as described above.
One cog on the Proplicator runs a modified version of the Propeller ROM boot loader. But instead of only listening on a reset, it listens all the time, and instead of downloading to the lower 32K of the EEPROM, it downloads to a higher area (I have some ideas for downloading multiple programs into larger EEPROMs but that's for later). A switch on the board disconnects the RTS pin from the RESn line of the Proplicator Propeller. When the switch is OFF ("Duplcation mode"), you can use the standard PropTool (or any other tool) to download a program from a PC; because the Propeller doesn't really get reset, the Proplicator software PRETENDS that the program gets stored in the lower 32K of the EEPROM but in reality it goes into the EEPROM area that gets duplicated by the other 7 cogs.
This idea should also come in handy for other production purposes. If Parallax doesn't have something like this in place already for producing e.g. the QuickStart (which is shipped with the touch-a-pad-to-light-the-LED demo program), they should work on it. All you need to do is connect a different jig, and use the standard way to download a program to the Proplicator, which then takes care of replicating that program to anything that gets attached.
As for customization, it would be possible to use the same Proplicator: the 8th cog could run a different program that reads data from the serial port (or you could connect a PS/2 keyboard to pins P30/P31) and modifies the EEPROMS of individual boards based on that information. For a large run of boards it would even be possible to store the list of users from the serial port to the Proplicator's EEPROM (remember the EEPROM can be up to 1MB) and write the information. Or you could use an SD card to store the program and customizations.
The only disadvantage is possibly that the USB-serial interface on the badges doesn't get tested this way...
...
I was thinking: It shouldn't be too hard to create a jig that lets you mount a board: basically just drop it in and twist a clamp or something to hold it down for programming. ....
I thought of what the most useful way would be to implement a Proplicator (hardware and software), and I think the best way would be this:
That sounds a good workshop parallel flow approach, and the pogo pins can be used for x1 in the field.
However, that's not quite an ideal customer end solution.
Longer term, I think another pass is needed on the HW, with maybe the SIM card connector I linked above as a 'neater pogo-pin' approach, for direct-connect fixture programming, (that can mount on a master-badge, in a much lower profile than a pogo-pin) and/or an added much faster IR_RX, as is done in the USB IR Toy v2.
One thought that occurred to me (and Ken touched on) involved using the IR for programming. Leave one badge connected to a computer, with firmware that basically turns it into an IR serial device. Of course, it might also make sense to make special hardware for this (e.g. a holder that ensures alignment of the IR components and keeps the guest badge's OLED easily visible).
To program a badge, you would:
Enter information in an admin application (portable, of course).
Place new badge face-to-face with the slave badge.
Press the power button on the new badge.
The new badge broadcasts (via IR) a startup announcement.
The slave badge immediate sends the "admin mode" message.
The new badge switches to admin mode.
In the admin program, press the "configure" button.
Once configuration is done, the user can exit admin mode by either cycling power on the badge or pressing the OSH button.
The present design is very slow on IR Link, but digging into the BOM & vendor info shows
* current IR design is PIN Diode + Amplifier VSOP38336 => 36 kHz, Envelope Decoded
However, Vishay have
* Amplifier VSOP98260 => 20-60 kHz Code Learning Amplifier, no Envelope Decode.
ie for Code learning, they skip Envelope decode and pass out carrier, allowing MCU to measure the carrier f, and modulation details in IR systems. This has much higher bandwidth.
VSOP98260 has same pinout as VSOP38336, but it has direct carrier out.
This does have a range trade-off, of 5m vs 45m, but 5m is surely plenty for Badge-Badge linking?
The VSOP98260 should allow Manchester encode, or maybe even the PWM encode P1 uses at 115200. - both would be over 10x present IR link speed.
Was the VSOP98260 ever tried in this design to see how the Speed / Range maps ?
I think the solution to Ken's original request must not involve hardware changes on the badge itself. There are already a large number of these badges made, so we need to work with what we currently have.
A web-based app can probably be written in Javascript if it is possible to access a serial port from JS which I believe it is.
Javascript does not have direct access to serial ports. However, it can interact with a locally-running server program that provides that access indirectly. That's how my SpinScope program operates.
There's what appears to be a server/client combo based upon node.js here:
Love it or hate it, another option very similar to Phil's could be to use a Java applet either embeded in a webpage, or run standalone. That would be compatible with windows, linux and apple OS, and (speaking from experience) can access the serial ports easily enough. In fact directly access the serial ports given the correct settings in the java code and manifest.
A web-based app can probably be written in Javascript if it is possible to access a serial port from JS which I believe it is.
Javascript does not have direct access to serial ports. However, it can interact with a locally-running server program that provides that access indirectly. That's how my SpinScope program operates.
There's what appears to be a server/client combo based upon node.js here:
Love it or hate it, another option very similar to Phil's could be to use a Java applet either embeded in a webpage, or run standalone. That would be compatible with windows, linux and apple OS, and (speaking from experience) can access the serial ports easily enough.
Just another option.
If you're going to run it as a standalone app, you may as well just use Qt like is done for SimpleIDE and PropellerIDE. The idea of Javascript was to be able to have the program served up as a web page without anything needing to be installed on the computer. If that isn't achievable, I'm not sure Javascript or a browser plugin is the right approach.
If you're going to run it as a standalone app, you may as well just use Qt like is done for SimpleIDE and PropellerIDE. The idea of Javascript was to be able to have the program served up as a web page without anything needing to be installed on the computer. If that isn't achievable, I'm not sure Javascript or a browser plugin is the right approach.
In the case of standalone I completely agree that keeping the same common Qt approach would be sensible.
As another option, the Java applet would enable direct serial control from a website, so could be a valid solution if the badge software might benefit from having a "no install required" solution.
In simple terms, you could connect the badge to a serial port, browse to the website, and then upload/download contacts directly. Without great effort I suspect the Propeller itself could also be programmed this way, although that's not within the remit here!
Seems like you already have the basics for this down already. Why re-invent the wheel? A wired or IR version shouldn't be to difficult to migrate from the wireless.
Seems like you already have the basics for this down already. Why re-invent the wheel? A wired or IR version shouldn't be to difficult to migrate from the wireless.
Yes, something like that could easily be used as the basis for this loader. That's one of the reasons I volunteered to help with this. I've already implemented Jeff's Wi-Fi protocol for Windows/Mac/Linux.
There are very few worries about conference contact info. Attendees are there to get it, and will typically provide info they don't mind being contacted with. This is typically name, title, email, phone, company, etc... Most of this can be had online easily for most attendees.
Having this be plaintext isn't an issue, IMHO.
Conferences typically sell, or rent, or at the least, guard attendee lists. Requiring access to that will require logistics and agreements that make the badges difficult to select.
Ease in selection really should be a primary requirement.
I think the solution to Ken's original request must not involve hardware changes on the badge itself. There are already a large number of these badges made, so we need to work with what we currently have.
Sure, any change is not mandated, existing Badges still work fine, just s l o w e r.
The idea is to think about what future builds of badges might look like, so code development now, does not 'wall itself in'.
That BOM swap looks worth testing to me- a big gain in speed, for a still useful range.
There is an "egg pad" to the left of the Propeller. Short that with something to reset.
So if you wanted a physical programming device, you could have a "press on" programmer with pongo pins which locates using 4 of the mount holes, and touches the reset egg and also 3V3, GND and the I2C pads at the right proto area.
A modified badge could be ideal! Perhaps we should make a programming shield.
The programmer could power the badge, hold the propeller in reset, and program the eeprom directly.
BUT... this still doesn't solve fast programming of contacts on-site. Something around the IR still seems plausable. It's the typing in of the contact info which is always the slow link.
What about to zap that info direct from customer phones? Have a gsm-programming shield / dock, where customers (having bought the badge), can go dock the badge and send an SMS to it. Hmm. maybe that just moves the queue clog from one place to another. And in this case, it would be simpler to have a few docks with real keyboards...
Hey- why don't we provide a ps/2 keyboard socket add-on ? could possibly connect in through the 3.5mm jack- that would be neat.
Have the pre-loaded badge software respond to ctrl-alt-del on the keyboard, which resets the badge and waits for the user to type in the name / etc. - with oled screen prompts. Gonna be faster than messing with usb connections surely ? And no multi-com port issues.....
So if you wanted a physical programming device, you could have a "press on" programmer with pongo pins which locates using 4 of the mount holes, and touches the reset egg and also 3V3, GND and the I2C pads at the right proto area.
A modified badge could be ideal! Perhaps we should make a programming shield....
.... That's one of the reasons I volunteered to help with this. I've already implemented Jeff's Wi-Fi protocol for Windows/Mac/Linux.
Merging those two ideas - perhaps adding a Wifi module to a 'programming shield,' that managed both direct-connect in various forms (pogo, SIM card etc) and IR links, and add a Keyboard choice.
I did not find PS2 to 4-pole 3.5mm cables, but there are PS2 to USB, so maybe a USB connector can be dual-purposed ?
Comments
Seems limiting and fairly basic too..
I just revisited i2c vs SPI flash, and the price trends are interesting.
i2c is pushed more into niche pricing, and a 128kB i2c part, is not just slightly more than 64k, but close to 2x.
Meanwhile SPI FLASH continues to fall, and I see
4 Mbit = 0.23848 @ qty 1,000
1 MBit = 0.21820 @ qty 1,000
i2c
32kB = 0.26163 @ qty 1,000
64kB = 0.42000 @ qty 1,000
That starts to look like a flip back to 32k i2c, with a SPI Flash makes more sense ?
Badges are hackable so hack away, but I think this is starting to get off topic. While making hardware changes to increase functionality is interesting we really should be focused on programming attendee info and reading back badge contacts based on the hardware we have.
Already covered in my earlier post, including a link to existing hardware and drivers you can use.
However, it is clear there are many limits and compromises with the present badge, (Storage is very low for a graphics display, Link bandwidth is very low for data flow )
When designing new software, only the truly blinkered would not also consider what the next badge might look like.
There's what appears to be a server/client combo based upon node.js here:
-Phil
Plug-in badge extensions is more challenging, but there are connection choices.
The BBC design uses larger plated holes designed for 4mm banana plugs, and edge connectors, or plated edge-holes are another way to make programming connections.
We have used clothes-peg type spring+clamp connections into holes for pgm.
Then there are SIM-card type connectors, this one looks like it has compliant pins : 21c/2k
http://www.digikey.com/product-detail/en/0475500001/WM11168TR-ND/
Could work with a clam-shell fixture for Master-Slave faster updates. (connector goes on master only, slave has very low cost, gold plated holes at the dome locations, with maybe a SMD part carefully placed to the notch, to give XY registration...)
Yes. See here: https://www.parallax.com/sites/default/files/downloads/20000-20100-Hackable-Electronic-Badge-Schematic-RevA.pdf
According to the DipTrace layout it.s only a 32K, (24C256):
http://www.mouser.com/ProductDetail/Microchip-Technology/24LC256-I-ST/?qs=wJ05WdDZ4qQ6WIuJTk%2bO%2bA==
A 24C512 would solder in the same place.
The IR parts may be a little different but both badges run 36Khz.
I busted out some IR parts from my Prop Education Kit and plan to mock something up with the badges I have. If I can get them talking I will go further.
ie range will be down a little, but testing should be ok.
As far as I can see, there were two main problems:
Both of these are very time-intensive, so it probably took maybe 10 minutes to program each board. That is unacceptable.
We're already discussing the possibilities of modifying the badge software so that it has a way to somehow change the owner's information in the same fashion as how a PC BIOS and Windows let you interrupt it while booting, to change settings. I've been thinking of how a program (which is now identical for each badge) can be downloaded to many badges (or other products) in quick succession.
I was thinking: It shouldn't be too hard to create a jig that lets you mount a board: basically just drop it in and twist a clamp or something to hold it down for programming. You can connect a number of those jigs to a device (let's call it the "Proplicator"), and make it run a program that downloads the badge software into the EEPROMs on the badges.
Each jig would connect to the badges via 5 pogo pins: VDD, VSS, RESn, SDA and SCL. The Proplicator pulls RESn LOW so that the badge Propeller doesn't start. The Proplicator can detect the presence of a badge because SDA and SCL have pull-up resistors (the Proplicator hardware should have some very weak pull-down resistors to pull SDA and SCL down when nothing is "jigged up). As soon as the Proplicator detects a board, it can use I2C to download the program to the badge's EEPROM. When done, it releases SDA and SCL and makes RESn high. That starts the Propeller on the badge using its own (now programmed) EEPROM. The program on the badge will make the display and LEDs work so the user knows that the board was programmed correctly and can take it out to replace it with another badge. With seven jigs working in tandem, this could go REALLY fast, you could probably get the handling time per board reduced from several minutes to several seconds.
I thought of what the most useful way would be to implement a Proplicator (hardware and software), and I think the best way would be this:
This idea should also come in handy for other production purposes. If Parallax doesn't have something like this in place already for producing e.g. the QuickStart (which is shipped with the touch-a-pad-to-light-the-LED demo program), they should work on it. All you need to do is connect a different jig, and use the standard way to download a program to the Proplicator, which then takes care of replicating that program to anything that gets attached.
As for customization, it would be possible to use the same Proplicator: the 8th cog could run a different program that reads data from the serial port (or you could connect a PS/2 keyboard to pins P30/P31) and modifies the EEPROMS of individual boards based on that information. For a large run of boards it would even be possible to store the list of users from the serial port to the Proplicator's EEPROM (remember the EEPROM can be up to 1MB) and write the information. Or you could use an SD card to store the program and customizations.
The only disadvantage is possibly that the USB-serial interface on the badges doesn't get tested this way...
===Jac
That sounds a good workshop parallel flow approach, and the pogo pins can be used for x1 in the field.
However, that's not quite an ideal customer end solution.
Longer term, I think another pass is needed on the HW, with maybe the SIM card connector I linked above as a 'neater pogo-pin' approach, for direct-connect fixture programming, (that can mount on a master-badge, in a much lower profile than a pogo-pin) and/or an added much faster IR_RX, as is done in the USB IR Toy v2.
The present design is very slow on IR Link, but digging into the BOM & vendor info shows
* current IR design is PIN Diode + Amplifier VSOP38336 => 36 kHz, Envelope Decoded
However, Vishay have
* Amplifier VSOP98260 => 20-60 kHz Code Learning Amplifier, no Envelope Decode.
ie for Code learning, they skip Envelope decode and pass out carrier, allowing MCU to measure the carrier f, and modulation details in IR systems. This has much higher bandwidth.
VSOP98260 has same pinout as VSOP38336, but it has direct carrier out.
This does have a range trade-off, of 5m vs 45m, but 5m is surely plenty for Badge-Badge linking?
The VSOP98260 should allow Manchester encode, or maybe even the PWM encode P1 uses at 115200. - both would be over 10x present IR link speed.
Was the VSOP98260 ever tried in this design to see how the Speed / Range maps ?
Love it or hate it, another option very similar to Phil's could be to use a Java applet either embeded in a webpage, or run standalone. That would be compatible with windows, linux and apple OS, and (speaking from experience) can access the serial ports easily enough. In fact directly access the serial ports given the correct settings in the java code and manifest.
Just another option.
In the case of standalone I completely agree that keeping the same common Qt approach would be sensible.
As another option, the Java applet would enable direct serial control from a website, so could be a valid solution if the badge software might benefit from having a "no install required" solution.
In simple terms, you could connect the badge to a serial port, browse to the website, and then upload/download contacts directly. Without great effort I suspect the Propeller itself could also be programmed this way, although that's not within the remit here!
http://forums.parallax.com/discussion/159869/programming-the-propeller-via-wireless-fast-what-happened-to-this
Wonder if having a Prop Plug port would have helped...
I don't see an exposed reset contact, or maybe you could have made a custom tool to do the programming...
Wonder if you can make or buy a tool that you can press onto the eeprom chip to do the programming...
Having this be plaintext isn't an issue, IMHO.
Conferences typically sell, or rent, or at the least, guard attendee lists. Requiring access to that will require logistics and agreements that make the badges difficult to select.
Ease in selection really should be a primary requirement.
The idea is to think about what future builds of badges might look like, so code development now, does not 'wall itself in'.
That BOM swap looks worth testing to me- a big gain in speed, for a still useful range.
There is an "egg pad" to the left of the Propeller. Short that with something to reset.
So if you wanted a physical programming device, you could have a "press on" programmer with pongo pins which locates using 4 of the mount holes, and touches the reset egg and also 3V3, GND and the I2C pads at the right proto area.
A modified badge could be ideal! Perhaps we should make a programming shield.
The programmer could power the badge, hold the propeller in reset, and program the eeprom directly.
BUT... this still doesn't solve fast programming of contacts on-site. Something around the IR still seems plausable. It's the typing in of the contact info which is always the slow link.
What about to zap that info direct from customer phones? Have a gsm-programming shield / dock, where customers (having bought the badge), can go dock the badge and send an SMS to it. Hmm. maybe that just moves the queue clog from one place to another. And in this case, it would be simpler to have a few docks with real keyboards...
Hey- why don't we provide a ps/2 keyboard socket add-on ? could possibly connect in through the 3.5mm jack- that would be neat.
Have the pre-loaded badge software respond to ctrl-alt-del on the keyboard, which resets the badge and waits for the user to type in the name / etc. - with oled screen prompts. Gonna be faster than messing with usb connections surely ? And no multi-com port issues.....
Merging those two ideas - perhaps adding a Wifi module to a 'programming shield,' that managed both direct-connect in various forms (pogo, SIM card etc) and IR links, and add a Keyboard choice.
I did not find PS2 to 4-pole 3.5mm cables, but there are PS2 to USB, so maybe a USB connector can be dual-purposed ?
Basically the software would loop waiting for a contact record as long as the contact record in EEPROM was blank.