Shop OBEX P1 Docs P2 Docs Learn Events
Need a quick-loader (and downloader) for Hackable Electronic Badge — Parallax Forums

Need a quick-loader (and downloader) for Hackable Electronic Badge

Ken GraceyKen Gracey Posts: 7,392
edited 2015-10-06 04:25 in General Discussion
Hey all,

We have a growing need at Parallax for a couple of interesting tools for the Hackable Electronic Badge. I'm not all that sure of the best way to approach this project at the moment, so I'm looking for suggestions since there are many ways to go about both projects. In short, these badges are customizable per event and identity. The badges are going to places where there are anywhere between 300 and 1000 people like art gallery openings, tech conferences and so on. They usually display somebody's name and also store e-mail, Twitter name, and so on. Through the event, the badges are used as a "contact manager" where they store each "introduction" in EEPROM.

Seairth and I already had a trial run at the Open Hardware Summit so he might have something to contribute here. Both of us can use Parallax programming tools of course, but this isn't the case for most of the "installations" where the badges will be sold. At the moment, you can look at the Propeller Spin code https://www.parallax.com/downloads/hackable-electronic-badge-ohs-spin-code to see how we (a) load the person's name and contact info and (b) use a terminal program to download their encountered contacts. You can also watch a short video I made https://www.youtube.com/watch?v=7fXuVUFoAXI.

The big gotcha here is that our badge tools need to be useful by anybody (without starting up Propeller IDE / Propeller Tool / Simple IDE and so on). These people aren't programmers - they might be event organizers, administrative staff, or volunteers.

So I ask a couple of questions:

1. What's the best way to easily load personal contact information into a badge (without a computer)?

The badge has infrared receiver, audio port, and buttons. The badge could be programmed at Parallax for event-specific behavior (logos, graphics, etc) so this tool would only need to load somebody's name and e-mail address. Firmware could have a listening capability for external input. It has a display, so it could show what's being typed if a keyboard were used. What about user-entered names with the touchpads to choose/select each letter? Ideas? Best to make application (2) below serve this same purpose for us? If so, fine!

2. Stand-alone, multi-platform, open-source computer program to download stored contacts?

At the event, people can exchange contact information by pressing the Open Hardware Button. LEDs confirm transmit and receive of the data over infrared (this works amazingly well thanks to JonnyMac's drivers). After the event the badge holder goes home and wants to download all of their new friends. At present, the firmware looks for any key press in a terminal program to start the 115,200 baud data dump back to the computer. Customers need to be able to do this without a terminal program. I believe we need a stand-alone, open, multi-platform program that does this for us (no Propeller programing tools required). It'd allow the contacts to be downloaded and saved as a simple text file on the computer. It would need to install FTDI drivers if not already present. Anybody can download and run the program. It just works.

Seeking any and all input on this issue. Please share your ideas here! My objective here is to determine the best model for this project. I'd like to determine the right development environment (web based? Python, so on) and then find a developer to do the project for us. Or, I might want to do this as a contest with a $2,500 bounty. For now, though, we need to get some discussion going and find the best design approach.

And yes, we will quickly need to write a specification for what we are asking for. That's probably our next task.

Ken Gracey
«13

Comments

  • SeairthSeairth Posts: 2,474
    edited 2015-10-06 11:55
    Yeah, I have a few thoughts on the topic.
    • The badge must be easily configurable without the use of the USB. (I am assuming that Parallax can trivially pre-program the eeproms with stock software.) This was a slow process at the conference. Programming a custom image to 1000 badges just isn't practical. Even if a stock image is pre-installed, it still takes time for the serial port to be installed and configured. And, at least on Windows systems, you will likely get a different COM port for each badge you plug in.
    • I would not want to enter initial setup data with the touchpads. However, the ability should still be available. There will inevitably be someone that needs a badge configured when there is no computer to configure it with.
    • Organizers also need to be able to do the following:
      • Edit the information without resetting the device.
      • Transfer all information from one badge to another. (I encountered this need when one of the customers appeared to have a faulty badge. Re-entering their personal information wasn't a big deal, but transferring their collected contacts was near impossible.)
      • Pull configuration information from a spreadsheet, database, etc. instead of manually typing it all in (this will dramatically reduce both time and errors).
    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:
    1. Enter information in an admin application (portable, of course).
    2. Place new badge face-to-face with the slave badge.
    3. Press the power button on the new badge.
    4. The new badge broadcasts (via IR) a startup announcement.
    5. The slave badge immediate sends the "admin mode" message.
    6. The new badge switches to admin mode.
    7. In the admin program, press the "configure" button.
    8. Once configuration is done, the user can exit admin mode by either cycling power on the badge or pressing the OSH button.

    Think of this like the PC's "Press F2 to enter BIOS". Note, of course, that once you have made it through step 6, you could perform any number of administrative tasks.

    For a bit of security, once the badge is configured, it would not do the startup routine described above. To enable it again, the user would set the badge to do it on the next startup.

    Anyhow, that's about all I've got for the moment. There were a few odds and ends that I noted somewhere during the conference. If I remember where I wrote them down, I'll be sure to put them here.
  • The app to download contacts sounds pretty easy. I suppose it will have to be a GUI app not a command line program so maybe Qt would be a good choice for a desktop app. 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. I'm looking forward to seeing a spec for this.
  • DynamoBenDynamoBen Posts: 366
    edited 2015-10-06 15:55
    Funny you mention this since I've been thinking about this myself. I'm thinking IR is the best option and creating either a standalone programmer or one that connects to a PC (or Raspberry Pi) is likely the best bet.

    What I have in mind is a docking station that the badge slides into, prior to inserting in the dock the user enters a badge ID number. This ID number correlates to the attendee info (contained in a list) and when placed in the dock the badge is then programmed via IR with the info.

    With this workflow the badges never need to be programmed prior to the event they can be done as an attendee registers, and if there is a PC or standalone programmer (keyboard and serial LCD) it could be done on-demand by manually entering info. The latter would be handy for events where people are able to buy badges day of. A programming kiosk either run by the event staff or attendee would be good for on-demand programming.

    As far as getting attendee info onto the badge, I'm thinking a "magic [IR] packet" could be sent to flip the badge into programming mode. From there we can use parts of the existing contacts transfer code to write the attendee info to EEProm and maybe even send a logo which could live on EEProm (a logo would eat up a bunch of space though).

    As far as getting the contact info off, why not eliminate the need for a computer and just scroll the contact info on the display. An attendee can use the buttons to advance through the list of contacts gathered. Simple, easy, no additional software to maintain/install and no compatibility concerns.

    Thoughts? (I have some thoughts on a stand alone programmer and may start mocking up a prototype)
  • How do you load the firmware onto a virgin badge over IR?
  • David Betz wrote: »
    How do you load the firmware onto a virgin badge over IR?

    You don't. Though it would certainly be possible to have a simple pre-loaded bootstrap loader that's programmed at Parallax. From there, you could use IR to program a conference-specific image (with custom images, menus options, etc.).
  • Seairth wrote: »
    David Betz wrote: »
    How do you load the firmware onto a virgin badge over IR?

    You don't. Though it would certainly be possible to have a simple pre-loaded bootstrap loader that's programmed at Parallax. From there, you could use IR to program a conference-specific image (with custom images, menus options, etc.).
    Okay, I misunderstood. I thought when DynamoBen said "with this workflow the badges never need to be programmed prior to the event" that he meant nothing needed to be pre-programmed into the EEPROM.
  • Security concern: So this badge when is use contains clear text contact info stored on an EEProm. If it were lost or stolen it would be a trivial task to get that data. Further if we create a web app now this data is susceptible to hacking. Encrypting the data via the Prop wouldn't be trivial and since our code is open source the encryption method(s) wouldn't be protected.

    So what options are there? If I had my way the only info transferred between badges would be attendee ID numbers, attendees then would be provided a list of contact info for that conference. The upside is you can store a lot more contact info to EEProm since you are only storing numbers, the downside is you need the list from the conference organizers either online or in print to get contact info (which could be tricky if badges are made on-demand at the event).

    I realize this is a bit off topic, but when thinking about mass production/use security becomes a concern.
  • DynamoBenDynamoBen Posts: 366
    edited 2015-10-06 16:05
    David Betz wrote: »
    Okay, I misunderstood. I thought when DynamoBen said "with this workflow the badges never need to be programmed prior to the event" that he meant nothing needed to be pre-programmed into the EEPROM.

    Right you would need a base badge image burned on them at the factory by Parallax. I'm only talking about the attendee info.

    That said mass programming is another interesting problem and being able to do that via IR would be a huge upgrade. While the Parallax loader works, plugging in 100+ badges and reprogramming isn't much fun. Having them all laid on a table (powered on) and reprogramming in mass via IR would be a lot easier, but arguably very tricky. However reprogramming them as attendee info is loaded seems workable.
  • DynamoBen wrote: »
    David Betz wrote: »
    Okay, I misunderstood. I thought when DynamoBen said "with this workflow the badges never need to be programmed prior to the event" that he meant nothing needed to be pre-programmed into the EEPROM.

    Right you would need a base badge image burned on them at the factory by Parallax. I'm only talking about the attendee info.

    That said mass programming is another interesting problem and being able to do that via IR would be a huge upgrade. While the Parallax loader works, plugging in 100+ badges and reprogramming isn't much fun. Having them all laid on a table (powered on) and reprogramming in mass via IR would be a lot easier. Or reprogramming them as attendee info is loaded could work too.
    Unfortunately, I think you'd need to change the ROM in the Propeller for that. I think the best that could be done is, as Seairth said, a small bootloader in EEPROM that would have to be pre-programmed at the factory.

  • DynamoBenDynamoBen Posts: 366
    edited 2015-10-06 16:08
    David Betz wrote: »
    Unfortunately, I think you'd need to change the ROM in the Propeller for that. I think the best that could be done is, as Seairth said, a small bootloader in EEPROM that would have to be pre-programmed at the factory.

    Transfer binary to lower part of eeprom via IR, reboot and transfer to upper part...new code loaded. SD loader code I believe works like this doesn't it? This might work: http://obex.parallax.com/object/218


  • DynamoBen wrote: »
    David Betz wrote: »
    Unfortunately, I think you'd need to change the ROM in the Propeller for that. I think the best that could be done is, as Seairth said, a small bootloader in EEPROM that would have to be pre-programmed at the factory.

    Transfer binary to lower part of eeprom via IR, reboot and transfer to upper part...new code loaded. SD loader code I believe works like this doesn't it? This might work: http://obex.parallax.com/object/218

    That's fine but you need *something* in the EEPROM to start. It can't be completely blank. Either that or you need a serial connection.

  • David Betz wrote: »
    That's fine but you need *something* in the EEPROM to start. It can't be completely blank. Either that or you need a serial connection.

    Agreed there is still a need for base code image from the factory.

  • DynamoBen wrote: »
    David Betz wrote: »
    That's fine but you need *something* in the EEPROM to start. It can't be completely blank. Either that or you need a serial connection.

    Agreed there is still a need for base code image from the factory.
    I think a bootloader that can receive an image over IR is a good idea though. I'd love to work on that.

  • DynamoBenDynamoBen Posts: 366
    edited 2015-10-06 16:27
    David Betz wrote: »
    I think a bootloader that can receive an image over IR is a good idea though. I'd love to work on that.

    So the risk in loading an image during attendee info programming is the amount of time it takes. Sending contact info is pretty quick, loading code I suspect wouldn't be. In addition there is a much greater chance of "bricking" the badge if code is loaded. I think having code loading as an option is important but it should be an option that only some would use (like me since I'm writing my own badge code).

    So I see three things happening in the dock I described:
    1. Loading only attendee info via IR.
    2. Loading new code and attendee info via IR.
    3. Loading only new code via IR.
    4. "Unbricking" by loading new code via serial. (optional)
  • DynamoBen wrote: »
    David Betz wrote: »
    I think a bootloader that can receive an image over IR is a good idea though. I'd love to work on that.

    So the risk in loading an image during attendee info programming is the amount of time it takes. Sending contact info is pretty quick, loading code I suspect wouldn't be. In addition there is a much greater chance of "bricking" the badge if code is loaded. I think having code loading as an option is important but it should be an option that only some would use (like me since I'm writing my own badge code).

    So I see three things happening in the dock I described:
    1. Loading only attendee info via IR.
    2. Loading new code and attendee info via IR.
    3. Loading only new code via IR.
    4. "Unbricking" by loading new code via serial. (optional)
    What about downloading contact information from a badge? Ken requested that feature as well.

  • BTW, how big is the EEPROM on the badge?
  • David Betz wrote: »
    BTW, how big is the EEPROM on the badge?

    64KB

  • DynamoBen wrote: »
    David Betz wrote: »
    BTW, how big is the EEPROM on the badge?

    64KB
    Thanks. I guess that means there is almost enough space for two full images. If the badge code is restricted to a little less than 32k, then there might be space for two images, the boot loader, and some contact and user data. We could even compress the images to fit two full 32k images. With two copies, we could validate a new IR download before switching to it minimizing the chances of bricking a badge. Of course, you're right that a 32k image would be quite slow to download over IR.

  • But then the whole Upper 32K would be needed for contact information as it is now?
  • Publison wrote: »
    But then the whole Upper 32K would be needed for contact information as it is now?
    I didn't realize that the entire upper 32k was already in use. I guess my idea won't work then. Sorry.

  • David Betz wrote: »
    Publison wrote: »
    But then the whole Upper 32K would be needed for contact information as it is now?
    I didn't realize that the entire upper 32k was already in use. I guess my idea won't work then. Sorry.

    This is true but the first step when the attendee info is added is the DB is cleared which is the upper 32K. So it's available briefly for other purposes.
  • PublisonPublison Posts: 12,366
    edited 2015-10-06 16:55
    I'll have to look at the code again, but I though contact info was stored there.

    EDIT:Contacts are store in Upper 32K

  • Actually, you don't really need two images. You can just use a single image as long as it's checksum verified before loading it. If the checksum doesn't match, you just stay in the bootloader waiting for another image. The only way you'll brick the chip is if someone downloads an image that then overwrites the bootloader.
  • DynamoBen wrote: »
    Security concern: So this badge when is use contains clear text contact info stored on an EEProm. If it were lost or stolen it would be a trivial task to get that data. Further if we create a web app now this data is susceptible to hacking. Encrypting the data via the Prop wouldn't be trivial and since our code is open source the encryption method(s) wouldn't be protected.

    So what options are there? If I had my way the only info transferred between badges would be attendee ID numbers, attendees then would be provided a list of contact info for that conference. The upside is you can store a lot more contact info to EEProm since you are only storing numbers, the downside is you need the list from the conference organizers either online or in print to get contact info (which could be tricky if badges are made on-demand at the event).

    I realize this is a bit off topic, but when thinking about mass production/use security becomes a concern.

    From a security perspective, I don't see an advantage of storing IDs instead of full contact information. If one can get the full contact list for a conference, then the IDs will still give you all you need. In fact, storing contact information instead of getting a master list will provide overall better security, since the thief will have only those contacts stored on the badge (and not the entire list).

    In reality, many conference organizers are going to be reluctant to give away a contact list like that. A requirement like this could easily prevent an organizer from using the badge at all.

    Besides, presumably the information that someone is willing to share via these badges is not going to be all that private in the first place. This information should be not much different than what one would print on a business card.
  • jmgjmg Posts: 15,173
    Seairth wrote: »
    And, at least on Windows systems, you will likely get a different COM port for each badge you plug in.
    That's a killer.

    Pretty much makes IR the main path, but a Master Badge could be possible.

    The master badge would manage USB-PGM and also store a full set of attendee details.
    Yes, that means a larger FLASH on the master, but flash is cheap.
    That then allows a simple menu-list update of any badge, no PC needed


    Overall the SW Driver and IR is a challenge, but for general IR links, google finds a very interesting USB IR Toy v2

    http://dangerousprototypes.com/docs/USB_IR_Toy_v2

    That mentions LIRC and WinLIRC drivers, and also shows what they learned over time.

    The v2 has added a faster IrRX for short range, but much faster, links.
    The QSE159 they use looks good for 115200+ baud, sub-cm range.

    Development could start using USB IR Toy v2, and the drivers, and then port to a Prop.
    (so the PC end works with either)


    That's a large 50x faster than the IR remote Baud.

    There are also SMD versions as OP181-OPL6000 Smart Meter Pair
    Those claim 'up to 256 Kbps operation'

  • jmgjmg Posts: 15,173
    Publison wrote: »
    EDIT:Contacts are store in Upper 32K

    How many contact records fit in 32k ?

  • SeairthSeairth Posts: 2,474
    edited 2015-10-06 18:04
    jmg wrote: »
    Publison wrote: »
    EDIT:Contacts are store in Upper 32K

    How many contact records fit in 32k ?

    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.
  • Ken,

    At one point, you were asking around for jumper wires that could press fit into PCB vias. Did you ever find something suitable? One of the reasons I'm asking is because the EEPROM is directly accessible via the proto area, since I2C is exposed. 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...
  • Seairth wrote: »
    From a security perspective, I don't see an advantage of storing IDs instead of full contact information. If one can get the full contact list for a conference, then the IDs will still give you all you need. In fact, storing contact information instead of getting a master list will provide overall better security, since the thief will have only those contacts stored on the badge (and not the entire list).

    Using IDs abstracts the contact info away from the device, since the device is most likely to be stolen. This concept is similar to how RFIDs are often abstracted from the actual user, ID is given entry privileges not a username/contact.
    In reality, many conference organizers are going to be reluctant to give away a contact list like that. A requirement like this could easily prevent an organizer from using the badge at all.

    Understood and maybe a full list isn't the right method and a bad example. Larger conferences provide badges with UPC codes that can be scanned by vendors so that they can follow up with you later. Often this is just a badge number and the organizer provides a list based on the numbers collected. Although QR codes are more popular and I'm not sure if they are doing just numbers or actual contact info.
    Besides, presumably the information that someone is willing to share via these badges is not going to be all that private in the first place. This information should be not much different than what one would print on a business card.

    I realize this and maybe nobody is worried about it, just highlighting a risk so people can make and active choice.
  • jmg wrote: »
    How many contact records fit in 32k ?

    Depends on the size of each record. I can't remember if the code limits length of record or not.

Sign In or Register to comment.