Chat logs about ZeroPhone/ZPUI
Conversations are in chronological order, with dates shown where they're known
- 1 IRC conversation about how ZPUI (what used to be pyLCI) works
- 2 IRC conversation about alternative UI toolkits
- 3 Modularity & self-assembly
- 4 Battery hotswap, LiIon power management and hardware addons
- 5 Ofono mailing list question about using ofono in ZeroPhone, #1
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]
Battery hotswap, LiIon power management and hardware addons
<MilkManzJourDadd> It would be nice to be able to carry spare batteries to eject a single discharged one, in a schema where one battery was used, then the other. I have used commercial handheld radios that had single batteries, carrying a charged spare with one charging. But those don't need to stay up like a smartphone. And in some situations you are not close to a charger. The phone could automaticly changeover from a spent <MilkManzJourDadd> battery to a charged one; then eject the spent battery and insert a charged spare. Would be very nice. <ArRay_> MilkManzJourDadd: if you let one battery discharge completely before switching to the other, it would be bad for the battery. <CRImier> ArRay_: how so? are you talking about LiIon battery specifics, if so, which ones? <ArRay_> Yes, fer Li-Ion <ArRay_> Going down to 0% isn't good <ArRay_> for* <CRImier> We never actually get to 0%, though - phones don't do that nowadays (even 5-10 years ago they didn't AFAIK) <CRImier> MilkManzJourDadd: I've thought about it, still considering it by now - no idea how to implement it (maybe some kind of "backup battery", even using supercaps?) You can safely changeover batteries while the USB is plugged in, though <CRImier> (MicroUSB charger) <ArRay_> Below 20% isn't very good either <CRImier> Hmm, that's interesting. Any references? <ArRay_> I don't know where I saw that… sorry… <CRImier> AFAIK desired charge level for storage is ~70%, I'm guessing that anything other than that, left for a long period of time, will negatively impact the battery <CRImier> But the 20% figure is indeed interesting <ArRay_> I think if you leave a battery for a long time it should be 50% <CRImier> (in terms of - what it means) <ArRay_> this is the first thing I find on duckduckgo https://www.howtogeek.com/169669/debunking-battery-life-myths-for-mobile-phones-tablets-and-laptops/ <ArRay_> there's also this https://forum.xda-developers.com/showthread.php?t=1168036 <ArRay_> (I searched lithium-ion battery "below 20%") <MilkManzJourDadd> CRImier: Thanks. <MilkManzJourDadd> ArRay_: I'm talking about independant batteries instead of two wired directly in parallel. And each with it's own control circuit where they could be charge or loaded independantly, and one could be swapped out while the other was loaded. This is better for device reliability and better for batteries as an expendable component as batteries are treated individually. <ArRay_> ok <CRImier> The ¨each has its own control circuit¨ part sounds complicated <CRImier> I'll see if I have some kind of solution <MilkManzJourDadd> Well, some sort of flip/flop logic gate, with voltage sensing, perhaps, as far as loading. For charging, perhaps just isolation diodes with a charging circuit that compensates for the voltage drop. But multiple batteries complicates things, while opening up options. Maybe some concepts might be borrowed from RV/Boating/Automotive designs. <CRImier> Loading? For proper voltage sensing, you mean? <CRImier> (as in, sensing voltage under the load) <CRImier> So, right now, it's done this way: batteries are in parallel with each other (divided by a fuse) and both are connected to a JST connector, which plugs into the back board. <CRImier> I'm thinking about adding a small battery/supercap that you could manually switch to. Once you've switched, you have a short amount of time to unplug the discharged battery pack/batteries and plug the charged ones. <CRImier> I have two different small powerpath breakout boards - one is based on FET+schottky circuit, one is based on LTC4413 <CRImier> If you're interested, I can send you one of both <CRImier> (with components already on) [...] <MilkManzJourDadd> What I mean is one battery is "under load"/in use while the other is in standby mode. When one battery is discharged to the arbitrary voltage level, the circuit switches to the other battery and if a charger is unavailable you could eject just the spent battery while running on the other. You could carry charged spares. A capacitor could buffer the internal changeover. <MilkManzJourDadd> I don't think you understand that I'm talking about Battery Isolation & Automatic Changeover. There is a lot of info' but let's take a simple example from Propane: <MilkManzJourDadd> https://www.hooktube.com/watch?v=4OIhFwwPq4M&start=25&end=143 <ArRay_> MilkManzJourDadd: how is it better than a regular phone backup battery? <CRImier> Because you can switch over without turning the phone off (while not having any access to 5V to charge the phone) <ArRay_> I mean the batteries that have a USB port on it <CRImier> I see. I'm interested in this kind of solution, but I'm not sure I'll be working on it myself - due to the amount of effort required to develop that in a way that's safe (and supports charging) <MilkManzJourDadd> You mean a the coin batteries soldered onto PCBs? Seriously?!?! That's like the CMOS/BIOS battery on a PC/Laptop. Above is like having a laptop with 2 main batteries where you… Yeah, thanks CRImier !!! <CRImier> For now, yes, a good workaround for swapping batteries is carrying a 1A-1.5A-capable powerbank and plugging it for the changeover interval <MilkManzJourDadd> You're still carrying something. <CRImier> MilkManzJourDadd - Didn't really talk about coin cells, there are various small LiIon batteries available on the market, and you can power ZP from these <CRImier> Yep, just like you need to carry spare 18650s regardless <MilkManzJourDadd> Well, maybe a capacitor. <CRImier> However, I'll make sure that one has the capabilities for developing such a thing - current 18650 holders already have both + split (though one of them is hardwired to JST), and you can already grab the 18650 files for Delta and start tinkering =) <MilkManzJourDadd> IDK, there is probably a circuit out there. The propane comparision is simple, but I have had vehicles with dual fuel tanks, and motorcycles with "reserve" fuel. It is nice. <CRImier> It's an interesting scenario, but there are already enough interesting scenarios for ZP available as it is, and I'm not sure I'll have the time =( However, if I stumble upon a suitable IC, you can be sure I'll throw together a proof-of-concept or two =) <MilkManzJourDadd> Yeah, maybe a small "daughterboard"/breakout-board or something. <MilkManzJourDadd> Thanks! <CRImier> + I offer hardware, promotion and advice to people developing something with a ZeroPhone <CRImier> (I should probably try and formalize that) <CRImier> Especially given that I have two spare 18650 boards for Delta, I can send one PCb to you for a start <CRImier> fnux: looked through my records, I do have a spare set =) <fnux> Nice :-) I will send you a mail this weekend (busy with exams right now). <CRImier> MilkManxJourDadd: so, thought about it some more. It seems we'll also need to somehow take charging into account. <MilkManzJourDadd> Well isolation diodes, accounting for voltage drop. Are you currently monitoring both batteries' temperature, voltage, et cetera, seperately? Despite being tied in parallel in the present configuration, they are seperate modules and there could be variations. <CRImier> Voltage - not separately, since they *are*, after all, tied together pretty well (doubt there's any significant voltage drop on those thick traces) <CRImier> diodes - > Then we'll need to add more charging circuitry, or risk undercharging batteries by a large amount <CRImier> since the charger would need to be able to measure battery voltage *after* the diode <CRImier> (like switching power supplies usually do with coils) <CRImier> temperature isn't monitored at all for now - 18650s are quite stable in that regard, that's what I rely on at the moment (also, the chargers ZP uses at the moment don't even have thermistor inputs available) <CRImier> Also, it's hard to add a thermistor since ZP uses loose cells ATM, those don't have any kind of thermistor output and it's mechanically tricky to add a thermistor to a loose 18650 <MilkManzJourDadd> Well, then it seems Voltage & Current are the way to monitor. <MilkManzJourDadd> Hmmm… There are plenty of multiple battery systems, some with multiple charging sources, out in production. Most are on a larger scale, but there must be a suitable I.C. <CRImier> Yep <CRImier> I'd go through Linear Technology (now Analog Devices) offerings, for a start <mozzwald> Max17043 for lipo fuel gauge. Sparkfun has a breakout <mozzwald> Linux driver avail. I used it on qwertypi <CRImier> I do have that breakout, but I'm not sure it's going to help much <CRImier> The 17043 is software-controlled after all, this would mean that battery management would be dependent on ZeroPhone <CRImier> Or some other chip, for that matter <CRImier> And, as far as I can tell, you'd use the 17043 for two things: 1) reading the battery voltage 2) getting the battery percentage from a chip that knows how to measure the percentage more-or-less correctly <CRImier> Any other usages for it? <CRImier> Moreover, IIRC the 17043 needs to be calibrated for a battery before it can even tell the percentage (and I'm not entirely sure we need the percentage in this case) <CRImier> Otherwise, 17043 seems no better than reading an ADC and using a lookup table to tell percentage <CRImier> To sum up, I'm not seeing any difference between having two 17043s and a MCU, and a MCU with two ADC channels <CRImier> mozzwald, am I wrong in this assessment? <mozzwald> Just for fuel gauge, it's good. Voltage and batt % is what it reports. Once it's 'programmed' for capacity, it won't lose that until battery/power is removed from it <mozzwald> As for the dual battery thing, i dunno if theres a chip for that <mozzwald> maybe easier to have two batteries charged by their own ic that feed into the regulator <mozzwald> so both batteries power system at same time and removing one doesnt shutoff system <MilkManzJourDadd> Is there any harm in using one battery at a time, then being able to remove the one that is deemed discharged? Having to deal with one discharged battery at a time seems advantagous over going, "Oh crap, I have TWO battery packs, but they are now BOTH DEAD!!!". <CRImier> MilkManzJourDadd: I don think there's any harm, the questions are: 1) how do we implement switchover 2) how do we take care of charging <CRImier> mozzwald, the power system of ZP is a tad more complicated than this <CRImier> (as far as I understand your proposal) [...] <mozzwald> CRImier: MilkManzJourDadd: no harm, just more complicated. what I proposed would basically 'replace' a single battery. the 'dual battery' would push and pull power but have it's own circuitry for each battery. <mozzwald> haven't really thought/researched the idea at all, just seems possible :) <mozzwald> you could make it more complicated using mosfets to separate power from each battery and use one until low, then switch to the other. but you'd need some logic to notify system/user which battery drained. [...] <MilkManzJourDadd> Anyway, if this were done, the ZF should automaticly Changeover. It's a distinct advantage of having multiple batteries, IMHO. <MilkManzJourDadd> Not trying to develop such is like having that RV propane system with multiple tanks but draining all at once or even one at at time but not switching over. You will wake up cold, or your shower will suddenly get ice cold!
Ofono mailing list question about using ofono in ZeroPhone, #1
From: Picugins Arsenijs To: "firstname.lastname@example.org" 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: email@example.com, 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, "firstname.lastname@example.org" 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.