Chat logs about ZeroPhone/ZPUI
(Redirected from Chat logs about ZeroPhone/pyLCI)
Conversations are in chronological order, with dates shown where they're known
IRC conversation about how ZPUI (what used to be pyLCI) works
<demon`> hi! I like your zerophone project very much! First of all I have no experience in design and functionality of mobile phones, neither from hardware, nor from software point of view. But I have some python experience and therefore forked pyLCI and digged little through the code. <demon`> My first question is more or less theoretical: Do you plan to use the GSM/baseband component like from the shelve or is it intended to use some open source solution like osmocombb there, too? <CRImier> Hi demon`! Great to have you here =) <CRImier> As for now, I'm using a SIM800 modem - it's a proprietary off-the-shelf baseband, I've pushed some code for working with it in pyLCI repo yesterday. <CRImier> I'll be looking for open solutions, and while OsmocomBB is great, it's not as accessible and cheap, so it's pretty much a stretch goal for the project =) <demon`> CRImier: thanks for your answer! :D What is the concept of the pyLCI code? (I did not understand why all these global references are necessary :-( ) <CRImier> Which global references, exactly? <demon`> CRImier: oh sorry, I did not see your answer. I mean for example those input and output references [...] <CRImier> So, about those i and o globals - it's the easiest way to pass input and output objects to UI elements, which can be used in many different places in a single app. <CRImier> When apps are loaded, init_app is executed from each app and it receives the input and output objects which are then assigned to globals <CRImier> The concept of pyLCI code is simple - it's mostly based on UI elements (Menus, Refreshers, Printers, Dialog boxes, Listboxes etc.) <CRImier> Once UI elements are called ("activated"), they set hooks on certain keys (for example, "LEFT" key almost always exits the UI element), using input object, and print something on the screen, using the output object. <CRImier> pyLCI is largely based on Menus - you select a menu entry, click on it and the associated function executes, and that's how 90% of the workflow goes (in general, that's how many user interfaces work.) <CRImier> For example, you can activate another Menu =) <CRImier> from a menu, that is. Or you could activate your function that'd do something useful. <demon`> [...] Thanks for the explanation! From my point of view I have always a bad feeling when I see global variables (because it's error prone IMHO). <demon`> What I did not really understand: Is this code multithread or is it singlethread? <demon`> Do you plan to put an object oriented application framework around your UI elements to get rid of the global variables? <demon`> And my last question: What is missing and easy to be implemented? (Because as I said, I am absolutely newbie in case of smartphone hardware and software, but have some experience in python) ;-) <demon`> I forked the pyLCI part of the zerophone repo; is there any branch on which should developed? is this the right fork I did? [...] <CRImier> The global variables can be problematic, but 1) the only two globals that really matter are i and o, and you're supposed to know about them when developing an app (and I don't recall ever making a mistake with this, since you're not supposed to have variable names that short anyway, though I see your point and will think of all possible problems ) 2) there isn't really a better way to do this 3) this is the simplest there can be 4) and you don't even <CRImier> have to use "global i, o" anywhere other than init_app function (which is pretty much boilerplate)). In the way they're used now, globals aren't much worse than, say, an imported function (like "from time import sleep"), or a global-level helper function. <demon`> CRImier: OK, yeah I thought so, too. But better to ask first ;-) <CRImier> The code is multithreaded - in fact - it has more threads than necessary =( https://github.com/ZeroPhone/pyLCI/issues/6 However, this issue needs some careful consideration - thread count will be eventualy minimized, but there can be no functionality loss. <CRImier> Most issues are on GitHub: https://github.com/ZeroPhone/pyLCI/issues If you want a simple one to start with, I can give you one =) <demon`> Yeah I would like to contribute to a small simple (and not time critical) task. :-) <CRImier> There's an UX issue that needs to be solved, it's about scrolling in Checkbox UI element. List-like UI elements have this "scrolling" feature, say, a Menu entry text is longer than the screen can show - so when you select that text, it scrolls to the right so that you can eventually read it all. <CRImier> Checkbox UI elements are like Menus, but first character that is shown on the screen is either " " (space) or "*" (asterisk), depending on whether checkbox entry is selected or not. When scrolling, that character also scrolls off the screen - which is an UX issue =( <demon`> Is there any app already implemented showing this Checkbox UI? <CRImier> Yep, for example, apps/media_apps/volume. There should also be a test app in apps/example_apps/ (something something checkbox), it should have the minimal app which has a Checkbox. <CRImier> I'd suggest you check the test app first =) <CRImier> About "Do you plan to put an object oriented application framework around your UI elements?" pyLCI uses tons of objects (also, pretty much everything in Python is an object) - all the UI elements (except Printer, it doesn't need to store state) are implemented as objects, input and output objects are also objects (with fair bit of inheritance), and, in general, it's reasonably object-oriented (statement based on my experience with various <CRImier> Python-based UI and other frameworks) <CRImier> IMO wrapping it in objects even more would probably result in having to write more code than necessary, which is not a good thing to do when developing something =) <demon`> Yeah, I saw that there are lots of objects. I just meant something like (class App: self.input, self.output, createThisAndThatObjectFactory(), ...) such that one can get rid of these global variables. But as you already said, as long as there are only two well-defined variables i and o there shouldn't be any necessity to define such an app class. <demon`> I also don't know how such a framework behave in a multithread environment <demon`> So these are questions only :-) <demon`> Thanks for the nice support, anyway. I will have a look at the test app, and if there are additional questions arising, I will ask you directly in this channel. Further I will open a small feature branch and pull-request from there once the bug is solved. :-) <CRImier> You actually can define such a class and instantiate it in init_app() , it's just that it isn't that necessary for things to work =) I remember working with Pyro two years ago, when I was trying to implement splitting pyLCI core and pyLCI apps. Pyro actually needs all the functions it passes back and forth to be objects - and frankly, it quickly became a pain to work with =( There can also be "too many objects", it appears. <CRImier> I can actually imagine a possible problem with those globals: "for i in range(10):", where i then becomes inaccessible for such function =D
IRC conversation about alternative UI toolkits
<SirCmpwn> I'm interested in UI work, but I'm not interested in basing it off of pyLCI <SirCmpwn> are our interests compatible? <CRImier> SirCmpwn: ...I don't know how to interpret this question =D It's my interest for alternative UI frameworks to appear for ZeroPhone, as well as make sure pyLCI stays separate from the control logic of the phone, so that other UIs can be integrated without having a systemd-like hostage situation ;-P <SirCmpwn> gotcha <CRImier> That being said, I'm also trying to avoid the OpenMoko-like situation, where, as far as I know, for a long time wasn't a single UI that just worked reliably and quickly. Therefore, I'm focusing on an UI that's going to "just work", and let others have all the experimenting fun =) <SirCmpwn> well, I'm working on a GUI toolkit in general <CRImier> What's your language of choice? is Python acceptable, or so-so? <SirCmpwn> whose design is flexible enough to accomodate situations like the screen constraints on the zero phone <SirCmpwn> well, my GUI toolkit is written in C and I intend to write bindings to other languages (including Python, I like Python) <SirCmpwn> but I question the viability of Python as a UI driver for an embedded device, at least with a fancier GUI than what you have going on <CRImier> Provided you have a Pi Zero, I can assemble you a quick "UI development platform" and ship it to you. It's basically a ZeroPhone front board made into a shield, you plug it onto a Pi Zero and get a screen, buttons, WiFi and audio output. <SirCmpwn> that would be cool <SirCmpwn> I don't have a pi zero but I can obtain one <SirCmpwn> https://github.com/SirCmpwn/chopsui fyi <SirCmpwn> I also do work with wayland compositors and it might be cool to make the UI driven by wayland <CRImier> I can ship it next Monday, even. As for "viability" - it works, as of now. It does consume a little bit more of CPU that I'd like it to, but the development speed is amazing, and the features provided allow to do really cool things (compared to what I, with my skills, could do in C). So, that's why Python is my personal choice for this - it's just the language I'm well-versed in, and it does allow some really cool stuff to be done quickly =) <SirCmpwn> sure, and the great thing about an open source platform (esp on Linux) is that you can use the tools you like <CRImier> I'll check out the GitHub in half an hour's time, now finishing up an order for a ZeroPhone parts batch <SirCmpwn> cool <CRImier> Wayland does sound cool, it's the great new thing, AFAIK - I'm not too well-versed in Linux GUI stuff to actually assess this proposal =D <SirCmpwn> well, it would allow you to extensibly do things like a notification bar, for instance <SirCmpwn> but it could be overcomplex considering that there isn't much screen to share anyway <CRImier> Yeah, Linux is great at development. I'm pretty much developing the whole ZeroPhone on a ZeroPhone, excluding the PCB stuff. <SirCmpwn> on the other hand, it would be nice to be able build applications in any language that can be a wayland client (i.e. any language) rather than having to write plugins for some less flexible UI system <CRImier> Where are you located, approx. (country)? <CRImier> I'm asking this because I can throw some links to hardware that you will likely need, from, say, Adafruit or Pimoroni. In practice, that's 1) Pi Zero 2) Pi Zero case of some sorts (a lasercut layered one works the best for me) 3) USB-OTG cable (microUSB to USB socket) 4) USB plug to microUSB cable (for powering the Zero). <SirCmpwn> CRImier: united states <SirCmpwn> and I just ordered a pi zero <CRImier> Adafruit? <SirCmpwn> I have a USB OTG cable <SirCmpwn> no, canakit <SirCmpwn> adafruit is sold out <CRImier> Did you order it with any extras? <SirCmpwn> power and a microSD card <CRImier> Adding an official case would be very handy - the shield is considerably larger than the Pi Zero, so it will benefit from some bulk added. <SirCmpwn> I'll just print something out <SirCmpwn> need an excuse to unclog my extruder nozzle anyway <CRImier> Oh, that's a great idea! <CRImier> https://cdn.hackaday.io/images//7764031505416771468.JPG <SirCmpwn> nice <CRImier> https://cdn.hackaday.io/images//5746471505416806332.JPG <CRImier> This is how what I'll send out looks like - just that I don't have neither Pi Zeros nor cases to send out =) [...] <CRImier> Send me your address, to zerophone at protonmail dot com . <SirCmpwn> can do <CRImier> [...] Do you mind if I share this conversation over at ZeroPhone Wiki? I try to save conversations which can be useful to others, so that they're accessible after everyone's chat logs are long gone. <SirCmpwn> sure, though I'm not sure what sort of useful information can be gleaned from this log <CRImier> My views about alternate UI toolkits, mainly =) I just believe that collecting bits&pieces of information like might be useful for somebody that wants to read as much as possible about the project, I know I work this way myself.
Modularity & self-assembly
<Turbowaffle> Is there any plan on making the front panel modular? It would be neat to be able to design different display/input options <CRImier> Turbowaffle: Well, the front panel is a separate module by itself, so you might as well replace that - there's not too much to it =) Also, it's possible to replace both the keypad board and the screen breakout with other boards - screen breakout header can be adapted for different pinouts, and the keypad is replaceable, too, it's even 2.54-grid based - you might want to reprogram the ATMega reading the keypad, though, if you're replacing the default <CRImier> keypad with something that differs a lot. <Turbowaffle> Neat. I ordered a set of boards a while ago to get a feel for the size and layout of things, and try to get my smd soldering mistakes out of the way. <CRImier> Turbowaffle: did you order some parts, too? <Turbowaffle> A few random things. An assortment of buttons, some ATMegas, one of the GSM radio breakouts. I have most of the passives already, just have to sort through them :\ <Turbowaffle> I was thinking of trying a 1.4" SPI e-paper display as an exercise to do some 3d modeling for KiCAD. I used FreeCAD a while ago for a few different projects, but nothing specific for 3D <Turbowaffle> (I have a set of the Gamma boards) <CRImier> I've got a 2" PaPiRus with a breakout, will do some hacking on it in order to add it as an additional display - that'll likely be during the crowdfunding. <CRImier> I've ordered some extra parts for Gamma boards, like protection boards (different boards will likely be used in the Delta revision, cause ones I picked seem to be harder to source). So I can send you those you don't have =) <Turbowaffle> Oh, sweet! I'll look at the BOM and see what I might be missing.
On using stacking headers for ZeroPhone assembly
<Turbowaffle> @CRImier, do you know the name of the types of header you're using in https://hackaday.io/project/19035/gallery#dd6cba5dabb2d1b990df357589a56389 <SirCmpwn> on the GPIO pins? <Turbowaffle> Yeah, the double rows <Turbowaffle> it looks like "round pin" is the key word, just found some on google <Turbowaffle> I've used them in a couple quad builds and I like how easy they are to take apart, but I don't have them in any quantity <Turbowaffle> Is there a close-up of the interface between the keyboard and the front board? It can't quite tell from the images how it's connected <CRImier> Turbowaffle: those are also called "machined pins" <CRImier> I only used those in the first version, they proved to be harder to work with than desired, at least, in this configuration - now I'm using default pins, in fact, since the second revision. <Turbowaffle> Interesting, good to know. Is any of the design dependent upon the size of the headers? I have some Pi stacking headers that are maybe 1.5 times the height of just the normal female headers <Turbowaffle> If not, I was thinking of designing my case to allow "spacers", so you could potentially hold more or less stuff [...] <CRImier> Turbowaffle: front board uses non-stacking female headers, and back board uses simple male headers <CRImier> I tried to get longer-than-usual male headers from China, but it turned out the seller that listed them didn't actually have them <CRImier> I guess that spacers would be a given if you were to design a lasercut case =) <CRImier> Can you maybe find a photo of your stacking headers? [...] <Turbowaffle> The stacking ones I have are like these https://www.amazon.com/gp/product/B01IRRCEBK/ <Turbowaffle> Nice! I've been putting off soldering anything to mine yet <Turbowaffle> @CRImier, the headers are the only interconnects between the boards, ya? [...] <CRImier> Yeah, ZeroPhone uses one male and one female header <Turbowaffle> I was planning on at least doing my first one with stacking headers so I can take it apart, because I will definitely do something wrong <CRImier> Turbowaffle: you can actually take apart the phone with the headers that I currently use. The catch us - the Pi Zero has to be soldered to the back board =( <CRImier> The best idea I've had so far, unfortunately. [...] <CRImier> I do have one Pi Zero with stacked headers, I use it for testing <CRImier> https://cdn.hackaday.io/images//4225181506640053009.JPG <CRImier> https://cdn.hackaday.io/images//9433071506640061609.JPG <CRImier> Basically, a Pi Zero soldered on some stacking headers. So, if I'm sending [only] back&front boards to somebody that already has a Pi Zero (provided I don't have one [to send along]), I can actually test [the boards]
Ofono mailing list question about using ofono in ZeroPhone, #1
From: Picugins Arsenijs To: "email@example.com" Subject: Running ofono on Raspberry Pi and SIM800 Hi! I'm interested in running ofono on a Raspberry Pi (BCM2835, 1GHz), connected to a SIM800 modem over UART (the stable Pi UART, not the MiniUART). I also have RST, DTR and RESET signals connected to the Pi, and for sound I'm using analog audio outputs and inputs of the modem. Basically, I'm talking about using ofono in ZeroPhone project - https://hackaday.io/project/19035 . For now, I'm interested in 1) notifications about voice call status (not concerning audio for now, as it's handled in hardware) 2) SMS and MMS support 3) 2G data connections (whatever available connection types are on 2G networks) 4) USSD support. My questions are: 1) Is ofono going to be suitable for my needs? I'm more than OK with using DBus and rolling my own user interface to it. 2) How do I run ofono from command-line and tell it to connect to a specific serial port and use a specific ofono driver? 3) Do you foresee any necessary changes to ofono? For example, need to make a sim800-specific driver? 4) I see that Sailfish phones are using ofono as the GSM backend. Did they upstream their changes, or do they have a fork? 5) I'm planning to work with SIM5320 modem in the future, and attempt using its USB connection. I know it creates multiple serial ports, and supports streaming audio over one of them. Does ofono come into play here, does it have some kind of provisions to convert this kind of audio input/output into actual sound devices under Linux, or is that usually handled by other software? Best regards, Arsenijs.
From: Denis Kenzior To: firstname.lastname@example.org, Picugins Arsenijs Subject: Re: Running ofono on Raspberry Pi and SIM800 Hi Arsenijs, On 10/18/2017 04:49 AM, Picugins Arsenijs wrote: > Hi! > > I'm interested in running ofono on a Raspberry Pi (BCM2835, 1GHz), connected to a SIM800 modem over UART (the stable Pi UART, not the MiniUART). I also have RST, DTR and RESET signals connected to the Pi, and for sound I'm using analog audio outputs and inputs of the modem. Basically, I'm talking about using ofono in ZeroPhone project - https://hackaday.io/project/19035 . > > For now, I'm interested in 1) notifications about voice call status (not concerning audio for now, as it's handled in hardware) 2) SMS and MMS support 3) 2G data connections (whatever available connection types are on 2G networks) 4) USSD support. My questions are: > > 1) Is ofono going to be suitable for my needs? I'm more than OK with using DBus and rolling my own user interface to it. It supports everything except MMS. That requires a separate MMS stack and is out of scope for oFono. I don't know of any full-featured open source MMS stacks, but I'm probably not paying enough attention. Maybe someone here can give you pointers. You can take a look at the (now undeveloped) mmsd project to see how the MMS stack should interact with oFono: https://git.kernel.org/pub/scm/network/ofono/mmsd.git/ > 2) How do I run ofono from command-line and tell it to connect to a specific serial port and use a specific ofono driver? You write a driver for it and since it is a serial port modem, use udev rules to setup the TTY port accordingly. See doc/sim900-modem.txt for an example. The device detection magic is inside plugins/udevng.c and most modem drivers reside in plugins/*. See the plugins/sim900.c, it may be close enough to the sim800 to get you started. > 3) Do you foresee any necessary changes to ofono? For example, need to make a sim800-specific driver? The most likely answer is yes. All new modems integrated into oFono required 'some' vendor/firmware specific handling. However, it is not possible to answer that unless you have the modem control protocol specifications in hand. If it is a standard AT command based modem, then the changes should be minimal. > 4) I see that Sailfish phones are using ofono as the GSM backend. Did they upstream their changes, or do they have a fork? They have a fork. > 5) I'm planning to work with SIM5320 modem in the future, and attempt using its USB connection. I know it creates multiple serial ports, and supports streaming audio over one of them. Does ofono come into play here, does it have some kind of provisions to convert this kind of audio input/output into actual sound devices under Linux, or is that usually handled by other software? oFono does not handle the audio bits. We can take care of sending the necessary AT commands to the device to configure the codec, etc. But the actual audio processing belongs in your audio daemon. E.g. PulseAudio or whatever. Regards, -Denis
From: Picugins Arsenijs To: Denis Kenzior, "email@example.com" Subject: Re: Running ofono on Raspberry Pi and SIM800 Thank you, that was a great answer. I'll focus on one part for now: Is it possible for me to run ofono from command-line, without involving udev? I'm asking this because, in my application, I'm using the UART as a debugging UART for first 30 seconds of phone's boot, then, if there's no activity (or other trigger set), I enable the GSM modem and run the GSM backend. Is there a reason why ofono is not capable to be run this way (provided it's not capable of this)? Is there a way I can just do the setup that udev would normally do, but manually? If so, where should I look for pointers - code, documentation or somewhere else? (doc/sim900-modem.txt? plugins/udevng.c?) Best regards, Arsenijs.
On 10/18/2017 11:40 AM, Picugins Arsenijs wrote: > Thank you, that was a great answer. I'll focus on one part for now: > > Is it possible for me to run ofono from command-line, without involving udev? I'm asking this because, in my application, I'm using the UART as a debugging UART for first 30 seconds of phone's boot, then, if there's no activity (or other trigger set), I enable the GSM modem and run the GSM backend. Is there a reason why ofono is not capable to be run this way (provided it's not capable of this)? Is there a way I can just do the setup that udev would normally do, but manually? If so, where should I look for pointers - code, documentation or somewhere else? (doc/sim900-modem.txt? plugins/udevng.c?) oFono can be started any time you wish. udev is just normally used to detect the hardware. Either via probing the USB bus, or in the case of serial devices via external configuration (e.g. udev rules). Without udev oFono would not know what TTY corresponds to the modem. E.g. on some platforms it may be ttyS0 and others it would be /dev/ttySAC0, or whatever. The oFono plugins / modem drivers are free to do anything they want. So if you want to hardcode the behavior, that is fine. You can always implement your own detection logic. For example plugins/phonesim.c uses a config file, plugins/rildev.c uses getenv. The possibilities are endless. udev is the preferred approach, other approaches might not be palatable to upstream. In terms of documentation or pointers, it really depends on your hardware setup. If you have a traditional AT command based modem with a multiplexer, then take a look at doc/calypso-modem.txt and plugins/calypso.c. This is the modem used on the original Freerunner. If you have multiplexing handled by the kernel, then the SIM900 docs / plugin might be applicable.