Have Solution, Need Problem - application for device I built

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: