Have Solution, Need Problem - application for device I built

[waldo22]

Dear Arsians,

I have developed and patented a product that I am no longer able to use for its originally intended purpose. It works fairly well, but it took us too long to develop, and the market moved on and now prefers newer ways to accomplish what this product was intended to do.

I'm not secretive about this, but I am being intentionally vague because I am hoping that folks will read about this and see the pictures and think "Wow, this is perfect for X application", so I don't want to bias your thinking toward anything related to our original idea. After vigorous discussion, I will be happy to tell everyone the rest of the story!

Instead, I will tell you everything about the product, and hope that you will tell me how your company wants to buy the product and the tools for your own use case.

We own all the source code for the device, the communication servers and the API, and have board schematics, gerber files, BOM, STEP files, etc, so I can provide you with plenty of info if you're interested. We also own the injection mold tooling, so we can make the product in volume or sell you the tooling so you can modify it for your own applications.

High level overview of the product:

• it is basically an 80mm thermal printer that receives something to print via the 4G LTE network
• after printing, it flashes and beeps (if desired, volume controllable via API) to get your attention
• pressing large flashing button acknowledges that printing has completed
• the printer can print the "payload" with a QR code or barcode
• the QR code can be scanned by the CCD camera on the other end of the device to send a message back to the API that sent it
• has WiFi and a BLE beacon, but WiFi logic flow is not implemented in software

Hardware details:

• all of the logic is controlled by a Microchip PIC32MZ EF processor
• connection to LTE is handled by a Simcom SIM7000A, which is also a full-featured processor with LUA scripting
• standard mini-SIM slot (what most people think of as a "full-sized" SIM)
• uses standard SMA male antenna for LTE
• PIC32 communicates with SIM7000A via UART and simple AT commands
• has an ESP-32 board for connecting to WiFi, Bluetooth, or acting as a BLE beacon
• PIC32 can communicate with ESP-32 via UART, also using simple AT commands
• thermal printer is an APS FM-305HS printer module and an ASIC controller with their custom firmware on our board
• uses standard 80mm (3 1/8") by 120 ft. paper rolls
• CCD camera is an Omnivision/Arducam OV7670 and Lens, mounted in "portrait" orientation, so images are 480x640
• unused USB-B female port on rear so it can act as USB host, no software implemented yet
• powered by a 12V, 5A power brick, overkill, but printer needs some power
• marginal cost to make an entire unit, including BOM, screws, plastics, etc, but NOT any assembly labor, was about $175
• I have datasheets on all of this stuff that I can attach if folks are interested

So it basically has 3 general purpose micro controllers with GPIO pins, SPI, I2C, RS232 UARTS, etc. Ideally the Simcom chip could have handled everything, but we had to have lower-level access to the hardware in order to do the image processing from the camera, so we used the Microchip PIC32. The ESP-32 is flashed with the AT mode firmware, but can use any firmware you desire if you want the full feature set.

API and communication details:

• our "firmware" that runs on the PIC32 is written in C and must be compiled with Microchip's MPLABx tools
• things you want to print are sent in JSON format to a REST-ish API written in Perl
• the print payload, along with unique ID, beeper volume, polling interval and other meta instructions, are saved by the API in a DB.
• in order to keep data usage low and eliminate the need for a VPN, the device "polls" the server with small UDP messages
• the UDP server, also in Perl (sorry), checks the DB for an entry to print and logs the poll as a "heartbeat" in the DB and logfile
• if there is nothing to print, the UDP server ignores the request and doesn't respond!
• I'd tell a UDP joke here, but I don't know if you'd get it
• if there is something to print, the UDP server responds that there is something to print
• the device then makes a new request via TCP for the print payload
• the TCP server is written in Go
• after receiving the payload, the device sends a "received" message via UDP in JSON format
• after pressing the flashing "acknowledge" button, the device sends a UDP "acknowledged" message in JSON format
• if you scan a QR code using the camera, depending on the QR, the device can
  • send a UDP JSON message of your choice back to the server
  • configure it's APN to tell it which LTE network to use
  • configure itself to use WiFi
  • basically anything else you want based on the QR payload
• the device supports OTA firmware updates for our code on the PIC32. If an update is available:
  • the UDP server responds to a poll with a messge saying so
  • the device then makes a TCP request to the Go server, and the server responds with the firmware update
  • PIC32 has 2 firmware banks in flash in case an update goes awry
• none of this uses encryption (except the REST API), because we don't use it for any sensitive data, so if you need secure messages/printing you'd need to implement a security layer on top of the UDP and TCP messages.

This communication design may seem crazy, but it turns out M2M data is still ridiculously expensive, and this allows a device to poll every 45 seconds for an entire month and use less than 3 MiB of LTE data if you aren't sending any messages. Sending 20 messages per day to be printed still uses less than 5 MiB/month total for our use case, but obviously will depend on message size and how many you send. We used "polling" instead of pushing becuase you can't initate a connection to a M2M device unless you pay for an expensive VPN and pay extra per-device fees monthly, and we were planning to deploy thousands of these. This keeps monthly costs low.

Obviously using WiFi solves this problem, but we wanted the device to work in areas without WiFi and also to not depend on folks breaking/changing the WiFi at the intended remote locations.

I have enough boards to build roughly 450 of these, and enough plastics to build about 1,000. They are currently in my garage, where they threaten my marriage on a regular basis.

Please share your thoughts and insights, and I'll let you know where to send the check.

Pictures:

Front of printer with paper, buttons, and tear bar


Left of printer with CCD Camera and ESP-32 w/ integrated antenna:


Right of printer with spring-loaded "acknowledge" button, SIM7000A and USB visible:


Rear with USB Host port:


Bottom with SIM tray, mounting holes, and 12V power port visible:

 

[Xenocrates]

This sounds almost like a device to handle rental/reservations of something that was supplanted by apps. Could be usable for things like exhibitors at a comiccon or similar where the WIFI is either expensive or spotty as well, to handle wait lists in a non-phone fashion.

 

[waldo22]

This sounds almost like a device to handle rental/reservations of something that was supplanted by apps. Could be usable for things like exhibitors at a comiccon or similar where the WIFI is either expensive or spotty as well, to handle wait lists in a non-phone fashion.

This is exactly the kind of comment I was looking for. I never would have thought of those things. Thanks!

Keep 'em coming.

 

[Wheels Of Confusion]

An installation that generates microfiction on demand? Maybe using the camera and an LLM on the back-end to personalize it to the receiver?

 

[Eric25020]

Xenocrates idea made me think of festival food services but I don’t know quite how it would fit in. Sort of a longer distance version of the waitstaff paper food order they hand to the kitchen.

Interesting device & pretty curious about its original purpose.

 

[waldo22]

An installation that generates microfiction on demand? Maybe using the camera and an LLM on the back-end to personalize it to the receiver?

I love this idea! That's really creative. Probably not much money in it though.

As for using the camera, we had to do all sorts of wizardry to get the camera to process QR codes, since the PIC32 has like 256k of RAM. A Raspberry Pi has a lot more power than this thing, but it's still useful.

 

[Neill78]

An order confirmation for food trucks that can be scanned with a smart phone to tell you your order is ready for pickup instead of waiting in line, and scanned back at the food truck to confirm pickup?

 

[The Aloof Alot]

Isn't this basically similar to the receipt printer part of an automated cashier in a supermarket? These consist of a scanner that you use to scan the barcodes on products, then you pay, and the printer prints out the receipt with a barcode/QR code, that you use at another scanner to leave the enclosed area that contains the automated cashiers.

 

[KD5MDK]

this allows a device to poll every 45 seconds for an entire month and use less than 3 MiB of LTE data if you aren't sending any messages. Sending 20 messages per day to be printed still uses less than 5 MiB/month total for our use case, but obviously will depend on message size and how many you send. We used "polling" instead of pushing becuase you can't initate a connection to a M2M device unless you pay for an expensive VPN and pay extra per-device fees monthly, and we were planning to deploy thousands of these. This keeps monthly costs low.

What's the ballpark cost of that 5 MiB/month per device if you had 10, or 100 of these? This is an area I know very little about.

What's the idle power draw when not printing? When I saw 12V 5A power brick my first thought was "power bank", not AC-DC transformer. But if you only need those 60W occasionally, more remote uses might open up.

 

[waldo22]

@KD5MDK sorry I missed your post; It's roughly $3 per device per month for 3-5 MiB with a M2M contract. Ours is with AT&T.

I haven't measured it but the power draw when idle is almost nothing. I'll see if I can put a ammeter on it. Almost all of the power is used for the thermal print head.

 

[waldo22]

Since it's been more than a week, I'll go ahead and tell everyone that we built this device to send food orders to restaurants to prepare for delivery, similar to what @Neill78 suggested.

My company is a restaurant delivery service like DoorDash, but we're just a small family business, honestly way too small to have taken on a project like this.

The device solves a hand full of problems:

• getting an order to the restaurant without having to make a phone call or send a fax
• getting confirmation they received the order; even when sending to a fax, email, or e-printer you had to call to confirm they received the order or you'd show up and the food wouldn't be ready
• when they press the "shut up" button, it sends confirmation to our API that they received the order
• It also eliminated relying on the restaurant's WiFi. You wouldn't believe how many times we got calls saying "your e-printer is broken, come fix it" when they changed their damned WiFi password or blocked it on their router
• provided the restaurant with a paper copy of the order ticket so they could take it to the kitchen without having to re-key it into their POS
• when they scan the QR, it sends our API a notification that the order is complete and ready for pickup. We can then send that information to our driver app so the driver knows to get their tail to the restaurant if they aren't there already

Overall I'm happy with the way the device turned out, but by the time we were ready to deploy more than a handful, people were using Android tablets with Bluetooth receipt printers, or even sending orders directly to restaurant POS systems (Toast, Revel, Clover, Square, etc.) either directly, or through a middleware provider like Deliverect, ItsACheckmate, Chowly, or Olo.

I was hoping someone would see this and want to buy 500 of them for their x business.

I'm considering open-sourcing all the code, including firmware, on GitHub and selling the devices one-off. If I do that, I can't provide the data plans, though, because I won't be able to control the data usage. Or at least I won't be able to ensure I get paid. If you accidentally program it to use 1 GB/month it would cost a fortune.

Let me know if any of you are interested in testing one, I can mail it to you.

 

[r0twhylr]

I don't have a specific use case for you, but I was just having a conversation with one of my wireless networking guys about wifi vs. 5G, and certain industrial floorplans that lend themselves better to 5G than wifi because the 5G signal floor is many db below wifi. Not sure whether that holds true with LTE also, but in some wifi wave propagation nightmare areas ( think industrial tank farms) a private 5G network is sometimes the best bet. I don't know what need there might be for a 4G or 5G remote printer in, say, an industrial IoT edge-computing use case. And if there were, you'd probably need to ruggedize / make a dust resistant version of your printer.

 

[Doomlord_uk]

by the time we were ready to deploy more than a handful, people were using Android tablets with Bluetooth receipt printers, or even sending orders directly to restaurant POS systems (Toast, Revel, Clover, Square, etc.) either directly, or through a middleware provider like Deliverect, ItsACheckmate, Chowly, or Olo.

How much of your market is taken over by these competing paperless or BT-printer services? Is there a cost-effective gap you can still fit into? I wouldn't expect so, because your manufacturing costs must be high especially for low product runs. But still, I think there are plenty of places that still use paper tickets... right? I can think of one I used to frequent, though they are too cheap/lazy to buy a 'solution' to their systemic disorganisation.

It might help to repost your request in the Boardroom section of the Ars forums for some input from a business rather than technical perspective.

 

[Doomlord_uk]

Is that a prototype you showed pictures of?

Is there any scope for optimising design for mass manufacture, and of getting some decent industrial design?

What are your patents on, exactly? This seems to offer a 'non-repudiation' function which is novel possibly, and would seem to help guarantee orders get through more safely. Downside is it's paper-based, which is just an expensive extra hassle in a world that is going has gone media-free.

I think you need to really focus on what your core business proposition is, not the technical implementation per se.

 

[Doomlord_uk]

the QR code can be scanned by the CCD camera on the other end of the device to send a message back to the API that sent it

This is weird. Your device remotely confirms by camera that it has done what it is supposed to have done? Why not a feedback sensor or three on the printhead and paperspooler? How often would this NOT print what you intended it to? That camera is expensive - why is it there?

[Edit] - last thought: If you are looking to unload between 450 and 1000 units and then 'that's it' then you are looking for a customer, or at least a customer type, with that many locations. I take it your company itself has no further interest in supporting or developing this further? Or is there some remaining 'breakeven' point either on unit sales or service/support fees that would warrant continuing this business?

 

[KD5MDK]

This is weird. Your device remotely confirms by camera that it has done what it is supposed to have done? Why not a feedback sensor or three on the printhead and paperspooler? How often would this NOT print what you intended it to? That camera is expensive - why is it there?

I think because printing the ticket doesn't mean it gets seen by someone in the restaurant. Having them scan it provides confirmation that the printout has been touched.

 

[waldo22]

This is weird. Your device remotely confirms by camera that it has done what it is supposed to have done? Why not a feedback sensor or three on the printhead and paperspooler? How often would this NOT print what you intended it to? That camera is expensive - why is it there?

[Edit] - last thought: If you are looking to unload between 450 and 1000 units and then 'that's it' then you are looking for a customer, or at least a customer type, with that many locations. I take it your company itself has no further interest in supporting or developing this further? Or is there some remaining 'breakeven' point either on unit sales or service/support fees that would warrant continuing this business?

There are 3 different things we need to confirm:

• The device received and printed the ticket (happens automatically when printed)
• A human has received the ticket (happens when they press the "shut up, we got it" button)
• The order (food in this case) is ready for pickup (happens when they scan the QR code on the ticket)

It's not a prototype, we had it done by an industrial designer and we own steel injection mold tooling for mass manufacture, but we don't currently have a system for mass manufacturing them.

We're not planning on developing it further unless we find a customer that wants us to. I'm flexible.

Our patents are for transmitting an order over a cellular network, so pretty broad:
https://patents.google.com/patent/US9361644B2/
https://patents.google.com/patent/US9384508B2/
https://patents.google.com/patent/US10402891B2/
https://patents.google.com/patent/US11301193B2/ (this is the strongest one)

 

[Honeybog]

Some random thoughts (without too much regard for monetization, novelty, or practicality):

I could see this being implemented in some sort of self-service inventory control system. Perhaps printing a slip on checkout that needs to be scanned on return, while updating inventory availability online.

Similarly, (and with a different printer?): A control system for tamper-proof/security stickers. Like, say, for verifying lock-outs in an industrial setting, or critical inventory (like crash carts in hospitals).

Some sort of timed admission system (scan on exit, like a parking garage). Say, maybe an all you can eat/drink event where charges accrue in 30-minute increments until the customer clocks out.

Maybe a reinvention of the grocery store manufacturer’s coupon dispensers that used to be everywhere 25 years ago. Say, for instance, someone signs up as a Conglomerate X insider and receives a member QR code. The customer scans their code at the store, the manufacturer gets some sweet marketing information, and, maybe leverages demographic/historical data to offer a bespoke coupon.

 

[waldo22]

Some random thoughts (without too much regard for monetization, novelty, or practicality):

I could see this being implemented in some sort of self-service inventory control system. Perhaps printing a slip on checkout that needs to be scanned on return, while updating inventory availability online.

Similarly, (and with a different printer?): A control system for tamper-proof/security stickers. Like, say, for verifying lock-outs in an industrial setting, or critical inventory (like crash carts in hospitals).

Some sort of timed admission system (scan on exit, like a parking garage). Say, maybe an all you can eat/drink event where charges accrue in 30-minute increments until the customer clocks out.

Maybe a reinvention of the grocery store manufacturer’s coupon dispensers that used to be everywhere 25 years ago. Say, for instance, someone signs up as a Conglomerate X insider and receives a member QR code. The customer scans their code at the store, the manufacturer gets some sweet marketing information, and, maybe leverages demographic/historical data to offer a bespoke coupon.

4 pretty clever ideas that I hadn't thought of, thanks!