We’ll say upfront that we don’t have nearly as much information about this 3D printed Star Trek: The Next Generation tricorder as we’d like. But from the image galleries [Himmelen] has posted we know it’s running on the Raspberry Pi Zero W, has a color LCD in addition to a monochrome OLED, and that it’s absolutely packed with gear.
So far, [Himmelen] has fit an NESDR RTL-SDR dongle, a GPS receiver, an accelerometer, and the battery charging circuitry in the top half of the case. Calling it a tight fit would be something of an understatement, especially when you take into account all the wires snaking around in there. But as mentioned in the Reddit thread about the device, a custom PCB backplane of sorts is in the works so all these modules will have something a little neater to plug into.
There are a lot of fantastic little details in this build that have us very excited to see it cross the finish line. The female USB port that’s been embedded into the top of the device is a nice touch, as it will make it easy to add storage or additional hardware in the field. We also love the keyboard, made up of 30 individual tact switches with 3D printed caps. It’s hard to imagine what actually typing on such an input device would be like, but even if each button just fired off its own program or function, we’d be happy.
Judging by the fact that the LCD shows the Pi sitting at a login prompt in all the images, we’re going to go out on a limb and assume [Himmelen] hasn’t gotten to writing much software for this little gadget yet. Once the hardware is done and it’s time to start pushing pixels though, something like Pygame could be used to make short work of a LCARS-style user interface that would fit the visual style of The Next Generation. In fact, off the top of our heads we can think of a few turn-key projects out there designed for creating Trek UIs, though the relatively limited computational power of the Pi Zero might be a problem.
We’ve seen several projects that tried to turn the iconic tricorder into a functional device. Some have focused on the arguably more recognizable Next Generation style such as this one, and others have targeted the more forgiving brick-shaped unit from Kirk and Spock’s era. The Wand Company is even working on a officially licensed tricorder that will supposedly be as close to we can get to the real thing with modern tech and a $250 USD price tag, though we’d wager COVID has slowed progress down on that one. In any event, whether you build it or buy it, the tricorder seems destined to become reality before too long.
Awesome! Kudos for that! :D
But wasn’t the Tricorder like TV Batman’s utility belt (or the gadgets given to James Bond at the beginning of the movies), always having just what was needed for that episode?
So a shark grabs Batman’s leg, and he just happens to have Bat shark repellant, and yet it’s never needed again and yet there was always something there when needed.
The Tricorder was less blatant, but always seemed to be given more power than it was defined from the start.
Tricorders are pocket supercomputers with huge amounts of information and every sensor that a full starship has except it only works out to a few metres. Somehow it’s possible to use all of this functionality by pressing just a few buttons, you can go from analysing the DNA of your friend to detecting time travel with just two button presses and a “bleep blorp”.
I have mixed feelings about that. 10 years ago I’d have agreed, but now… on your phone – can you tell the difference between an email notification, the battery going flat and whatsapp? It’s like it’s own language (bleepbleeeeeep blipboop)
I would at least have to do a search for the time travel detection app after I’d closed WhatsThat
So like a big, ungainly Sonic Screwdriver then. ;)
Haha, yeah. At least the Doctor is canonically telepathic.
The sonic screwdriver is more of a manipulator doing stuff tool as opposed to the primarily detector/sensor capabilities of the tricorder. For manipulating and doing stuff, Star Trek has had all sorts of glowy tools that I am not sure if they ever got proper names in canon.
Sort of, but it was more consistent than it looked because the technology wasn’t thoroughly explained on-screen.
24th Century tricorders had a subspace link to the nearest ship or base, just like the combadges, and typically functioned more like a remote sensor probe while sending the sensor reading back to a centralized computer and receiving analysis results quickly. Considering Federation computers used optical computing, this sort of data analysis would have been absurdly efficient which explains the rapid turn-around. Sort of like current cloud-based deep learning applications.
When there wasn’t a ship or starbase nearby, again just like combadges, tricorders would transition to a much more limited analysis capability, often requiring several minutes, hours, or in at least one case several years to analyze the sensor readings and find any useful patterns.
If we could sort out superluminal wireless communications and ultra low power optical computation, we’d have a lore-accurate 24th Century tricorder.
Obviously the manufacturer provides an excellent update support :-)
Well, between the transporter and replicator tech I wonder if the Tricorder couldn’t operate like an FPGA on steroids!
Not that there’s any textual evidence or acknowledgement of such a thing. ;)
“Not that there’s any textual evidence or acknowledgement of such a thing. ;)”
I acknowledge your smiley, but just want to mention all the various “Star Trek Technical Manual”s out there that “explain” the inner workings.
it’s an impressive job off cramming but it seems to me like the point of a tricorder is the sensors.
but seriously why is everyone using a cpu with no idle mode in battery-powered doodads? ever since i’ve learned that i’ve had the most derogatory feeling towards this whole hobby of shoving pis in things. do people really have so little discernment they can’t tell that a cpu with no idle mode isn’t acceptable in this kind of function? it tells you right off, this device is a gimmick for the clicks and photos, and isn’t ever going to be used. anyone that uses this thing would be absolutely infuriated at how much heat and dead-battery that idle shell prompt is creating.
every single one of these portable pi devices winds up not being used in practice. every one of them! a few people with actual embedded requirements might figure out how to do the full poweroff to use a pi in a timed sensor package but for user interface it’s a total non-starter.
The Pi is derived from tablet/phone CPUs. These normally are optimized for portable battery powered devices, so I can not imagine, that the CPU should not have an idle mode.
Is this not used in the Pi or is this the fault of the operating system?
i could not imagine it either! but it is true! its idle temperature is 45C and i’ve found numerous threads of people complaining about this and being reassured only that the device can tolerate much higher temperatures without damage.
it’s possible a kernel change could fix it but it looks likely that the closed proprietary VideoCore accelerated processor which functions as a bootloader and BIOS is misconfigured and unrepairable without an epic hack.
Probably fault of the OS that’s too busy doing lots of stuff in the background to go into sleep mode. For what this prop is supposed to do, it is overkill.
Interesting point. What would you suggest instead?
for actual use, it’s hard to beat a cheap phone / tablet / laptop. i guess i come off too harsh, i don’t mind that people build something useless as a hobby or art project it just really bums me out when it *could* be useful but poor choices in closed software guarantee it will never be more than a novelty.
Which completely fails to be comparable to any Pi… Phone/tablets are usually garbage as soon as the maker stops pushing updates, almost impossible to add hardware to, and are a pita to try and use for anything outside of their normal functions. And laptop motherboards are huge! At least in comparison, and often have no GPIO at all, so you will always need to use a USB slave device should you want user defined IO, which might well need as much extra power as the Pi (zero?) you could just use for that whole task instead…
I’d also not say at all they are only a novelty – its a very useful amount of computing performance in a small, well supported package with GPIO, and in the case of CM4’s PCIE too…
Also I’m not sure its at all “insurmountable” to improve idle power and thermals (infact the Pi foundation have historically pushed updates that do just that), its just not worth it enough for anybody else to try – An idle but ‘on’ pi doesn’t draw much power anyway, heck even flat out a pi 4 doesn’t draw all that much – less than any of my laptops at idle by a huge margin, and that is with the pi 4 running flat out!.
Also you can define down the clockspeed hugely and stay stable – not entirely sure how much power such playing saves, still just playing around pushing the boundaries without a great deal of science level documenting (as that is both tedious and slow when you are just after a feel for the pi’s capabilities and if its worth looking at it for x type of project).
Also there is the concept of halted for the pi, with wake on gpio, and wake on global enable options so if you want stupendously long standby times you can have them…
Or in short you can do just about anything you like with a Pi, sure some parts are still disappointingly closed source, but the documentation for users is superb and the versatility imposable to come close to with your phone/tablet (except maybe those new Pine and full fledged Linux phones)… Sure both phone/tablet and laptops might be a better starting point for your particular needs, but the single board computers, particularly the really well documented ones like the Pi’s are far from useless novelties (though they certainly can be built into such things if that is what the maker desires).
It definitely has an on-off mode to. conserve battery. I agree, an Arduino might handle most legwork for such a device.
it’s not that it’s overpowered, it’s that it doesn’t idle. my smartphone has a much more powerful processor and can go into a low power mode where it will wake in a microsecond but is drawing no power in the meantime. even my modern intel celeron n4000, when it is not executing instructions, it barely draws power. broadcom may be the exception but in generall all of these mobile-oriented processors have a low power mode on execution of a HALT or WAIT instruction (which linux calls from the idle task which consumes 97.0% of my CPU time) that is extremely effective, no matter how powerful the processor is when running full tilt. but the challenge comes when there is something still “on” that doesn’t respond to that HALT instruction. it means hunting through all the device drivers looking for one that keeps a high power drive running when it’s not in use, or something in that vein. but the broadcom at the heart of pis is so closed off that such a search on a pi runs very quickly into this question: how do you power down the other components within the SoC? and you can’t readily do that because they’re all hidden behind a closed firmware that apparently makes very bad choices by default.
it’s probably a solvable problem (in software) but pi is decently old and no one’s solved it so it seems the barriers in the way of solving the problem are effectively insurmountable.
What about this one https://youtu.be/Xh7VfrmUPGU
Kept the original look, runs on Pi and has loads of features! PiCorder The Next Generation