Teensy Display Conundrum

Status
Not open for further replies.

dauntless89

Well-known member
I've been searching for years for a suitable display option for my Teensy-based project. The display requirements are a daylight-readable 7"-ish touchscreen with a decent refresh rate. I have been scouring the available options for a good while and haven't found anything I like that can be used without major reinvention of the wheel. The project is an engine monitoring/management/datalogging system for use in the motorsports sector.

Previously, I had planned on hard-mounting the display in the test vehicle and controlling it directly from the ECU with an RA8875/6 or some other driver board. Now, I am thinking my best play from an ease-of-use and cost-effectiveness perspective would be to get a tablet, make an app for the GUI, and interface the ECU and the display over one of several connections. While I initially wanted to avoid this, I'm now thinking it would be more convenient for my use. I might be able to provide a little more reasoning but this is not an open-source project, so I may not be able to offer all the context.

The main question I have now is what connection protocol I should use. wifi, Bluetooth, or a soft-wired connection such as USB.

I am leaning towards Bluetooth, as this is method has already been used for similar devices in my industry, doesn't require a master/slave relationship like wifi would, and could allow connection of multiple devices without physically moving a cable around.

The problem with this is I have zero experience working in Bluetooth, wifi, or USB in the context of between a Teensy and some other device. I am perfectly willing to learn, but I need to start with the "right" protocol for my needs because my time is a factor. I don't want to have to start with (for example) wifi and then have to abandon it in favor of bluetooth for some reason I don't find out until I'm months down the rabbit hole.

I would appreciate advice for selecting a protocol, and a brief overview of the strengths and weaknesses of each approach, as a complete picture of this information has eluded me in the context of something like my project. It would be nice to be able to connect to the ECU simultaneously from multiple devices (for example, in case a situation comes up where it makes sense for a co-pilot to datalog on his personal device while I drive and am using the monitor function on the "main" display) but I don't think this is necessarily required. One specific area of interest is bandwidth. Someday, I may be monitoring as many as 100 sensor inputs (values ranging from boolean to single-precision float) simultaneously, and it would be ideal if the connection could support the display logging these values at reasonably fast rates (>100Hz) as well as sending certain commands back to the device. I presume that in 2020, this is really a "rookie numbers" type of bandwidth requirement, but as I said, I haven't messed with it before.

Any input would be greatly appreciated. Thank you.

PS - Another thing I wanted input on is signal strength. The ECU itself will be mounted inside a steel NEMA 1 enclosure bolted to the cab floor of the vehicle (it is grounded to the chassis). The display will be mounted near the driver's windshield pillar. If I go with a wireless option, would I need to mount the antenna externally, perhaps under the dashboard, or should there be enough signal strength at that short range to not be an issue?
 
Last edited:
Just to give the ball a first kick: I'm currently tipping my toes on BT (firmware to connect a medical device to an Android smartphone), and used WiFi in the past for a custom project (performing art project).

There are many BT variants around, and if you need iOS (Apple) compatibility, your choices are restrict to v4.0+
There are BT modules which are quite simple to use because of a companion MCU (example: HC-05, restricted to BT 2.0): they expose a convenient AT interface so you can talk BT without the need of libraries.

BT is low-power-centric so is neither fast, nor long range. Usually we are talking about 10-100 KB/s; latest implementation maybe 400. Typical usable range is some meters (say 10-20) in open air.
If your unit is inside a metal case, I doubt it would be possible to reliably communicate with it even if 1m away only.

For WiFi, you typically resort to well known chipsets and libraries, so no low-level communication.
I used a TCP socket; simple and effective.
Signal could be strong enough to pass the metal case with an embedded antenna only.
Since the communication is multi-layered (TCP on top of 802.11 on top of radio modulation), delay could be a few ms, maybe 15-20ms for a round-trip.
Bandwidth is plenty.
Lot of different versions; most common is 802.11n @ 2.4 GHz, OK for every Android tablet/smartphone; presumably OK for Apple devices too.
 
Status
Not open for further replies.
Back
Top