I'll be releasing the schematics when the codebase has been cleaned up and is stable. I also found a critical hardware bug in the LiPo charging circuit which could be dangerous so once the issue is fixed, I'll release the PCB.
There's no plan to commercialize the device. However, I hope that the hacker community will eventually help take the device to the next level through hardware and software enhancements.
Regarding voice... The board has a MEMS microphone linked to PWM and the STM32H7 has sufficient bandwidth to compress voice in real-time and package it ready for transmission. I plan to add short message voice transmission soon.
Regarding LoRa and LoRaWan... there have been suggestions to greatly improve range by piggybacking the things network. I'm investigating this. Currently, the network implementation is a simple self-healing mesh network. It features route discovery and low power performance. Standard Semtech LoRa drivers have been implemented with some important modifications to queue interrupts (better for low power management)
PCB traces... 50 ohm impedance traces have been match length tuned for high speed NAND memory interfaces. Featuring a QuadSPI interface, the bus can operate at 160 mhz. While not super fast by todays standards, it's a nice feature.
4K encryption... It's not marketing hype or a play on 4K screens. I added incredibly strong encryption, just because it could be done. Fun to do and probably not needed... #overengineered
Nokia e71/72... the PCB can be EASILY adapted to suit those cases. I'm thinking about doing it. Anyone like to assist?
Operating system... I'm using FreeRTOS as the kernel with custom device drivers for scattered throughout the codebase to handle the keypad, RTC, LoRa radio, LCD screen tearing, USB port, MicroSD card etc.
Debugging and development enhancements... I plan to 3D print a chassis to hold the phone when debugging. For this to work, the PCB needs to have pads placed strategically around the battery area so that when it's docked, the SWD debug header, trace pins and power sources are exposed to the debug chassis pins. Next PCB version.
If you have any questions.... shoot. I'm happy to discuss the device here on the forum. If you have collaboration ideas, I'm open to hearing them.
There's no plan to commercialize the device. However, I hope that the hacker community will eventually help take the device to the next level through hardware and software enhancements.
Regarding voice... The board has a MEMS microphone linked to PWM and the STM32H7 has sufficient bandwidth to compress voice in real-time and package it ready for transmission. I plan to add short message voice transmission soon.
Regarding LoRa and LoRaWan... there have been suggestions to greatly improve range by piggybacking the things network. I'm investigating this. Currently, the network implementation is a simple self-healing mesh network. It features route discovery and low power performance. Standard Semtech LoRa drivers have been implemented with some important modifications to queue interrupts (better for low power management)
RF... the PCB features a tuned 915 mhz antenna + a microcoaxial RF connector for an external antenna. 50Ohm impedance tracing. http://www.farnell.com/datasheets/1867459.pdf
PCB traces... 50 ohm impedance traces have been match length tuned for high speed NAND memory interfaces. Featuring a QuadSPI interface, the bus can operate at 160 mhz. While not super fast by todays standards, it's a nice feature.
4K encryption... It's not marketing hype or a play on 4K screens. I added incredibly strong encryption, just because it could be done. Fun to do and probably not needed... #overengineered
Nokia e71/72... the PCB can be EASILY adapted to suit those cases. I'm thinking about doing it. Anyone like to assist?
Operating system... I'm using FreeRTOS as the kernel with custom device drivers for scattered throughout the codebase to handle the keypad, RTC, LoRa radio, LCD screen tearing, USB port, MicroSD card etc.
Debugging and development enhancements... I plan to 3D print a chassis to hold the phone when debugging. For this to work, the PCB needs to have pads placed strategically around the battery area so that when it's docked, the SWD debug header, trace pins and power sources are exposed to the debug chassis pins. Next PCB version.
If you have any questions.... shoot. I'm happy to discuss the device here on the forum. If you have collaboration ideas, I'm open to hearing them.
https://github.com/TrevorAttema/OTGMessenger