It would be more proper to compare baresip to PJSIP/pjsua. I'm using both and both are great, with multiple unique features. The strong point for pjsip would be in my opinion pjmedia conference bridge (easy to use and powerful mixing, volume control, audio format conversion), this basically has no equivalent in baresip. I also do like PJSIP layered project code organization more. On the other hand baresip is slightly ligher in terms of memory usage (more suitable for e.g. STM32F4). And while PJSIP licensing is not that expensive (considering the size and maturity of the project), baresip would be free most of the times even in commercial projects thanks to BSD license.
Well, consumer SIP is mostly dead. 20 years ago mobile calls were quite expensive, now they are basically free. Also the marked matured, people are more educated in general and using default port was never a good idea.
V.23 FSK is just the name of modulation. You can have CLIP receiver as separate IC (https://www.microsemi.com/product-directory/caller-id/4305-m...) or as some DFT code with Goertzel algorithm with maybe 0.1 MIPS DSP budget allowed. No sane person would add full modem capabilities to this.
That said, PABXs I worked with have built-in software modems (both POTS and ISDN, needs to be explicitely enabled) with remote management capability and there is also dedicated web portal for management even if device is behind NAT (paid feature). Whether you want to trust hardware/software you have no control of - that's another story. For "big" PABXs partnership between manufacturer and installers usually lasts for years.
The other caveat is that time spent configuring, troubleshooting and later maintaining them would be worth much more than 10 dollars. Their use is discouraged by many SIP providers (https://teamhelp.sipgate.co.uk/hc/en-gb/articles/204210961-C...) and they have multiple issues not obvious at first glance, like limited character set for Display Name. This might be worth though for 100+ phones in a single location.
I remember these phones had some interoperability issue: https://answers.microsoft.com/en-us/mobiledevices/forum/all/... (technically all according to specification, but often not working for incoming calls). At the time Symbian was supported by pjsip though.
I do believe that Cisco SIP implementation in 7000 series phones is non-interoperable by design. One major issue is that they are sending SIP messages from different port than the port they are receiving on. Because of this they practically do not work with any kind of NAT and I haven't heard of any consumer service provider that would work with this (the standard behavior is to assume that port passed in Contact line might be incorrect). Some of phones from that line have "NAT" true/false setting, but some don't - when tracing changelog I saw that this setting was removed in later firmware version, but for many phones this earlier firmware version was never available.
There are some USB "phones" - basically composite USB devices with audio and HID, where HID is used to handle keypad and display (if present). I'm using very cheap EX-03 "Skype" phone: https://tomeko.net/software/SIPclient/EX03.php but similar devices are also made by big brands, they are just more expensive (Polycom CX300, Plantronics Calisto, Yealink MP50 maybe?) and probably undocumented.
I think Delphi Started has same limitation as C++ Builder Starter - removed most of debugging functionality (e.g. local variables window). It may be not critical with small applications, but I would rather have "no commercial", no 3rd party components or code size limitation than crippled IDE.
I've tried to switch from Turbo C++ Explorer 2006 (this was also free version) to C++ Builder 10.1 Starter and I prefer old one.
Not necessary much higher. I've measured screen flickering in Lenovo T500 (probably one of the oldest laptops with LED backlight) with small solar cell and oscilloscope and it's 220Hz, with lowest brightness setting only 100Hz (although this brighness level is not too useful):
http://commonemitter.blogspot.com/2017/06/lenovo-t500-measur...
Nope. There is chip looking like PMU on board with at least two output power rails. For VoCore 1 there were two MT3410L converters, one for 3.3V and one for 1.8V. With switching converter total power consumption should be close to SoC power consumption, not depending on input voltage.
Also specification is pretty clear: 74mA wifi standby, 230mA wifi full speed, 5V input. Input voltage range: 3.6V ~ 6.0V.
It is a generalized statement. Very few SoCs have internal switch mode controllers. It is going to either be an LDO, or take a fixed operating voltage. Requirements for such will be specified in current, which is more useful than power.
Module level specs would be irrelevant in engineering because there is little incentive to use something like this, the radio isn't even certified. On that note, get your popcorn ready for when they ship to German backers and customs proceeds to trash them.
> Very few SoCs have internal switch mode controllers.
That's why PMUs are used. Just look at bottom side of the PCB - there are three coils, two of them very close to the chip looking pretty much like PMU.
> It is going to either be an LDO, or take a fixed operating voltage.
