FloJack vs Spark+NFC Shield

[DieterParticipant]

Ordered and paid 04/07/2013.
Notified upon FloBLE and registered 03/2014.

We have 13/02/2015 and there has been no notification or update or product shipped ever since. No refund received.

Is there any update on this order?

[RichardKeymaster]

Hi Dieter, still no production progress with the FloBLE. However, we are shipping FloJacks (v2) now so I moved your order back to processing and will ship it out as you originally ordered it. Sorry for the delay and appreciate your patience with us.

[RichardKeymaster]

I assume the address on your account is still current? Let me know so we can process you order ASAP.

[DieterParticipant]

Hi Richard,

Thanks for your answer!

If “no progress” means that there is no time frame for the FloBLE then I would actually appreciate a refund more then a shipment.

If refund isn’t an option, then yes, my address is current.

Regards,
Dieter

[RichardKeymaster]

Hey Dieter, yeah can’t afford a refund but will ship you FloJack out immediately. We have a powerful SDK that will all you to build some interesting applications, so I hope you haven’t given up on NFC because of our poor execution. With device ubiquity now achievable with the FloJack, there’s use cases are are open up in several vertical markets.

[DieterParticipant]

Hi Richard,

Thanks for your attention and the shipment.

I’ll take a look into the SDK, to see what I can do. There is no giving up here. I am a system architect/technical product management team member for an “NFC” based security product.

Besides, I have actually built a reader that works for iOS through WLAN using a NFC shield and Spark Core, a BLE Module is on the way as well….

Regards,
Dieter

[RichardKeymaster]

That’s phenomenal. I’d be interested in learning what challenges, if any, you faced with that approach. I’m familiar with Spark and shield based solutions and wondered the following:

• Does the self-assembled nature make it less appealing as a product?
• Do dimensions and unpolished enclosure options still meet requirements?
• Is the friction of swapping Wifi access point a problem? Would BLE be better, worse, same for your application?
• Does the NFC stack supported through the open source community provide features for secure element, authenticated read/writes, and NDEF support?
• How easy was it to build and install this NFC stack?
• Was the NFC stack in the form of Arduino sketches or such that PN532 commands were abstracted for a web app/mobile app to issue (Python, Javascript, etc)?

Thanks in advance for the feedback. This helps us focus our energy into niches that can provide value given the rapidly expanding IoT space.

[DieterParticipant]

– It’s not a product, rather a prototype, started because there is no low cost reader product available for iOS devices (yeah, originally the plan was to use the Flomio product as such)
– Enclosure will be designed and made professionally if it makes it into a product
– Not for the current use case, it is supposed to work as an NFC Reader for an iOS device to administrate access to media in iOS.
– Most of the stack is now custom written; secure element is not required, because it is supposed to be a reader not a medium. Target is MIFARE, in particular DesFire so there is an encrypted session between the controller and the medium for all operations (the reader is a detector and a tunnel)
– Building was some effort, installing is a breeze with the Spark Core. Debugging for Mac is easiest with a serial to usb adapter.
– The NFC stack is written for the Spark in C. It handles PN532 directly over SPI. The WLAN side is abstracted into a relatively simple request-response protocol for the mobile app.

Hope that answers your questions 🙂

Regards,
Dieter

[RichardKeymaster]

Thanks Dieter, that totally helps. It’s great to be able to discuss these topics with people skilled in the art. I have a few more comments/questions if you’re not too annoyed by them yet:

• We’re opting to put Secure Elements in each of our readers because we’ve learned it’s hard to make money selling only hardware. Like in the case of the FloJack, we made the first batch but then leveraged ACS for our current version. DUKPT key management allows us to preload shared secrets for each FloJack order and make sure our stack is protected (good enough). So customers can opt to buy from us or directly from ACS, but only units bought from us will work with our SDK and Apps (coming soon). This is the only way we could come up with to stay in business while offering compelling price points to customers like yourself.
• We’re keen on providing a seamless interface for applications like yours to port over to this model. So that once you receive your FloJack or if later you consider a FLoBLE, that the switch will be painless.
• Given that, what are the configurations you’d be interested in for managing the reader beyond the ISO7816-4 request-response protocol? Sniffer circuit tuning? Reader polling rate? LED control? BLE state control? Battery level? Firmware upgrades?
• Is it worth offering some abstracted services like authenticated_read_block(key, address) and other higher level methods on top of ISO7816-4?
• Is it worthy to offer this in a Cordova plugin vs iOS or Android native interfaces? Do you see your development efforts shifting to a web hybrid approach any time soon?

Thanks again for your feedback. This is incredibly helpful.

[MarcParticipant]

Hey Dieter

It sound very interesting what you are doing:

“Besides, I have actually built a reader that works for iOS through WLAN using a NFC shield and Spark Core, a BLE Module is on the way as well….”

Is it possible to contact you?

Best
Marc

[Author]

Posts