Phone app/service using GSM module

My idea is to develop an app or service (further discussion is needed) to add GPS and GSM capabilities (that is, mobile phone) to the Flipper. This can be done connecting to an external GSM module using the GPIO pins.

For the external hardware I will be using the Adafruit’s Fona 808 Mini Cellular GPS + GSM breakout, which integrates the SIM808 chip. This chip allows 2G network connectivity for voice and data. Any other flavour of FONA, or even other breakout or custom boards with the SIM808 chip could work for a collaborative project.

I know this is not an “intended” use case of the Flipper Zero (because I think that low level control of the GSM radio is not allowed) but still I find it an interesting project to integrate this with the current kernel. For people interested in cellular networks and open software/hardware, this could be a great start for a “mobile phone” project from the ground.

Actual features, code structure and specific details are still to be thought about and discussed. So please, if someone is interested in developing this or something related, this forum is the place to start!

5 Likes

I like the idea.

Ok, so for anyone that wants to follow the progress or participate, I’ve been thinking on which should be the roadmap for this to get real. These are the tasks that I think should be done:

  • Port the Adafruit FONA Library to the STM32 architecture (low-level, interact with hardware) or the FURI HAL/FURI CORE platform, using the Flipper OS’s APIs (higher-level).
  • Study the Flipper’s GPIO and prototype a schematic to connect the FONA breakout board to the Flipper.
  • Develop the service that will connect to the FONA and interact with it, using the library
  • Develop the application that will provide the functionatlity to the user
  • (Less priority) Design a 3rd-party module with the SIM808 chip that better integrates with the Flipper.

So when I have some time I will start with the port of the library, I will publish here the link to the fork repository. I suggest that discussions specific to each task but that relate to the general approach follow this post in the forum, and that specific design topics can be discussed in github issues.

This pull request of a refactor of the library from years ago might be a good start read to understand which components are AVR/Arduino specific and should be changed. I also have read that the library is completely built over the assumption of a software serial library in the platform, which I am pretty sure the STM32 platform does not have.