Announcement

Collapse
No announcement yet.

Announcing Nobdy

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Announcing Nobdy

    In light of what's going on with osdash, and the result of many discussions with malcom and chunky_ks (aka chunky kibbles, aka gary), I'm finding a gap in the current obd software offerings. Thus I am proposing the "nobdy" project to solve those issues.

    Rationale:

    - Normally, only one obd app can access the scantool at a time. You can use a multiplexer on the port (maybe xport?), but that requires extra software.

    - Logging is an important feature IMHO of an obdapp. Maybe you want to do logging and only sometimes display gauges and graphs on the screen. Current software offerings are first a graphical app, and secondly a logging app (if at all). They require you to run the UI to get logging.

    - What about GMLAN? Or any other non-standard bus that you can get good info off of? There's currently no way to get anything custom from standard obdII apps (correct me if I'm wrong).

    - There nothing that solves all of the above and runs on both windows and Linux and/or Mac.


    Nobdy

    Nobdy is a plugin based daemon that allows provider and subscriber plugins. A provider would be something that reads information off the bus for the subscribers. There can be an infinite amount of subscribers. A subscriber could be a logging application, a gauge application, or an OSDash client. All of these subscribers would be able to get information from the core without locking the others out.

    This will be written in c++/Qt and will work on Linux, Mac and windows. The core daemon will be very simple, very fast, and very light.

    The core also supports exchanging "providers" with other providers. You may swap the generic ELM provider with one more suitable for reading CAN messages or even GMLAN messages. You could even swap in a provider that reads from the megasquirt ecu thingy.
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  • #2
    Great idea! Solves a classic problem that GPS apps have had to deal with for some time, but for OBD.

    Question - is it reasonable to consider this an OSDash service, even though it runs locally? I like the idea that location of the service is irrelevant.
    Originally posted by ghettocruzer
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

    Comment


    • #3
      It could be. Depends on the plugin's capabilities (ie, the plugin would have to be RESTful accessible via apache or something). I was planning on making a proper osdash service to allow configuration of what pids you are interested in logging remotely as well as a cloud-ish way to sync the log db and view it on your desktop.
      Former author of LinuxICE, nghost, nobdy.
      Current author of Automotive Message Broker (AMB).
      Works on Tizen IVI. Does not represent anyone or anything but himself.

      Comment


      • #4
        I just like the idea that it sort of turns the server idea on it's head. You might normally think of a service as running on a server on the net and requiring a net connection. But you really don't have to do that. It can run on your PC.

        Which would allow you to access it from a client on a different machine. Like a mobile phone.
        Originally posted by ghettocruzer
        I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
        Want to:
        -Find out about the new iBug iPad install?
        -Find out about carPC's in just 5 minutes? View the Car PC 101 video

        Comment


        • #5
          Originally posted by Bugbyte View Post
          Great idea! Solves a classic problem that GPS apps have had to deal with for some time, but for OBD.
          Actually, it is a slightly different problem. In GPS, there is a basic set of information that all client software is interested in.

          In OBD-II you have a scarce resource, the limited capacity of the ECUs in the vehicle to respond, being distributed for different needs.

          Take tuning versus an MPG gauge. If I'm trying to log data for tuning, I'm interested in different pids than an MPG gauge. And, I often have to be very careful in selecting them because the ECU can only respond to a limited number of channels fast enough for my purposes. In other words, if RPM stair steps because the ECU is busy providing MAP, IAT, and VSS for an MPG approximation, the data is worthless to chart against AFR for tuning.

          In this case, the user might like concurrent apps, until discovering that the collected data is degraded to the point of not being useful.

          It also gets trickier if one app is using make/model specific information and another is not. If I want to put an ECU in MUT, SSM, or even fast GM modes, and another app wants to keep making J1979 requests, there is a serious bus conflict.

          I don't mean to be a naysayer, in fact, there might be some real use in distributing basic information to multiple apps. Our push model might even be well suited for it, since it has a priority mechanism and already minimizes communication latency. But is hard for me to see how more sophisticated functionality is going to get away from 'one app at a time'.

          -jjf

          Comment


          • #6
            I have similar doubts about the idea, but I'm more than happy to be proved wrong.

            I'm going to move the OBD comms part of logger into its own library soon, and hopefully that'll be something that trip can build on for writing nobdy. I'm just concerned that when push gets to shove, it won't *actually* work usefully. It seems wasteful to not share at least that much code :-)

            There's a certain amount of caching PIDs with a timeout, and scheduling based on priority [eg, 0100 can safely be cached forever], and things like that, but in the end, if you can only sample 20 pids a second, and the logging applet is trying to log eight of them twice a second, I just don't see how the bandwidth will work out once you have more contention.

            I have more general naysaying vibes, but I'm not gonna post them here, because I think it's actually a good idea to have a service like this, if such a thing can work. And just because I don't see how it will work in practice doesn't mean that someone smarter than me can't figure it out :-)

            Gary (-;
            OBDGPSLogger, for logging OBDII and/or GPS data
            OBDSim, an OBDII/ELM327 software simulator
            mp3car forums: obdgpslogger, obdsim

            Comment


            • #7
              Originally posted by jfitzpat View Post
              Actually, it is a slightly different problem. In GPS, there is a basic set of information that all client software is interested in.

              In OBD-II you have a scarce resource, the limited capacity of the ECUs in the vehicle to respond, being distributed for different needs.

              Take tuning versus an MPG gauge. If I'm trying to log data for tuning, I'm interested in different pids than an MPG gauge. And, I often have to be very careful in selecting them because the ECU can only respond to a limited number of channels fast enough for my purposes. In other words, if RPM stair steps because the ECU is busy providing MAP, IAT, and VSS for an MPG approximation, the data is worthless to chart against AFR for tuning.

              In this case, the user might like concurrent apps, until discovering that the collected data is degraded to the point of not being useful.

              It also gets trickier if one app is using make/model specific information and another is not. If I want to put an ECU in MUT, SSM, or even fast GM modes, and another app wants to keep making J1979 requests, there is a serious bus conflict.

              I don't mean to be a naysayer, in fact, there might be some real use in distributing basic information to multiple apps. Our push model might even be well suited for it, since it has a priority mechanism and already minimizes communication latency. But is hard for me to see how more sophisticated functionality is going to get away from 'one app at a time'.

              -jjf


              There are going to be huge latency issues if used improperly... and this is something that end-users are going to quickly realize. Priorities are a core component of this approach which from my experience help some, but the idea behind this is not to speed up communications. It is to allow more applications to use obd2 data at once. If every application needs speed, rpm, and maf then it would be no slower than a single application requesting it.

              If you're tuning, you're likely not using a frontend anyway (Or you have something very custom built). This is more of a generic solution to open up more possibilities for obd2 information. GPS has speed based volume, locationally aware activities and properties (Getting weather or lowering volume in certain areas). Why not give the opportunity for more applications to take advantage of OBD2 data in a similar way? Say your frontend doesn't support obd2 logging, or you want to embed an external application to have gauges, but also log, but your frontend uses obd2 for it's speed based volume or some other reason. This would allow you to be able to do all of this.

              As for bus conflicts... that's going to be up to the end-user to be sure they are not conflicting. I'm not 100% up on the logistics of this, as I don't have this issue my car is very simple.


              I think it boils down to If you can't do something normally you shouldn't expect to be able to automagically do it because of this application.. If you can't request 30 different pids with a decent refresh rate, then you can't expect 2 different applications to request 15 different pids each with a decent refresh rate.
              "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
              RevFE
              My Shop

              Comment


              • #8
                Originally posted by chunkyks View Post
                And just because I don't see how it will work in practice doesn't mean that someone smarter than me can't figure it out :-)
                I don't know if this will help, but imagine you want to use a gauge display application that doesn't support logging... but it's the most beautiful gauge display. You want it embedded into your frontend of choice of course. You also want logging... but you're SOL because you can't have your cake and eat it too. This service would get around a situation like this, and I personally see that as the primary example.


                As a secondary example: Say you have your gauge display application... but you just got a check engine light. Your frontend supports checking obd2 codes... but you'd have to go in, close down your gauge display, then restart your frontend to connect to the com port... etc etc.
                "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
                RevFE
                My Shop

                Comment


                • #9
                  I don't know if this will help, but imagine you want to use a gauge display application that doesn't support logging... but it's the most beautiful gauge display. You want it embedded into your frontend of choice of course. You also want logging... but you're SOL because you can't have your cake and eat it too. This service would get around a situation like this, and I personally see that as the primary example.
                  That's one problem that obdgpslogger actually explicitly solves right now. Tell it the things you want logged, and your gauge application can listen for the dbus signals [and, of course, there's nothing stopping me from adding more signalling mechanisms].

                  If you don't like dbus, there's a couple other ways to do that work right now:
                  1) scrape the database [I did write a gimpy prototype to try this, and it works, but I never committed it]
                  2) launch logger yourself, and read the stdout messages [which is how obdgui works]

                  The things that it *doesn't* solve right now:
                  1) Requesting specific things - you can't tell obdgpslogger that you want it to add a specific PID to the list of PIDs it's sampling
                  2) Only works with dbus [*gag*]
                  3) Doesn't currently signal errors or have the ability to clear them, although the code to do that is already half-done.
                  4) Doesn't currently have a manufacturer-specific mechanism for anything.

                  ... but if all you want is to display gauges, I explicitly have a couple mechanisms to do that.

                  Gary (-;
                  OBDGPSLogger, for logging OBDII and/or GPS data
                  OBDSim, an OBDII/ELM327 software simulator
                  mp3car forums: obdgpslogger, obdsim

                  Comment


                  • #10
                    Originally posted by chunkyks View Post
                    That's one problem that obdgpslogger actually explicitly solves right now. Tell it the things you want logged, and your gauge application can listen for the dbus signals [and, of course, there's nothing stopping me from adding more signalling mechanisms].

                    If you don't like dbus, there's a couple other ways to do that work right now:
                    1) scrape the database [I did write a gimpy prototype to try this, and it works, but I never committed it]
                    2) launch logger yourself, and read the stdout messages [which is how obdgui works]

                    The things that it *doesn't* solve right now:
                    1) Requesting specific things - you can't tell obdgpslogger that you want it to add a specific PID to the list of PIDs it's sampling
                    2) Only works with dbus [*gag*]
                    3) Doesn't currently signal errors or have the ability to clear them, although the code to do that is already half-done.
                    4) Doesn't currently have a manufacturer-specific mechanism for anything.

                    ... but if all you want is to display gauges, I explicitly have a couple mechanisms to do that.

                    Gary (-;

                    1-4 is exactly why i see the need for this app (minus #2 as i'm obviously okay with that ). Obdgpslogger is a beautiful thing, but i think we've discovered it's limits. I'd really love to have bluemonkey lock and unlock my doors by sending messages over the bus. My car supports it, but obdgpslogger doesn't. Nobdy can do it though. We both know that logger was built to do one thing and one thing really well: log. I kinda got you to make it into a deamonic (and daemonic) interface to obd-ii for LinuxICE, but that was an afterthought to the original design.

                    As for latency, I really don't see the problem. If you are using nobdy for tuning, you aren't going to be running a bazillion other apps/plugins that add latency to information you care about for tuning. You're probably going to have one plugin and that's it. Maybe you'll add gauges to that, but there is likely going to be a lot of overlap to the data you are gathering for tuning and the data you are displaying. the data is also cached in such a way that 100 plugins/apps can requests pid 0x0ff but only one request goes on the bus and the response is sent out to the 100 plugins. Malcom's pid priority code also helps. You can ensure that logging gets a higher priority over say, the plugin that is constantly checking for trouble codes.
                    Former author of LinuxICE, nghost, nobdy.
                    Current author of Automotive Message Broker (AMB).
                    Works on Tizen IVI. Does not represent anyone or anything but himself.

                    Comment


                    • #11
                      Originally posted by tripzero View Post
                      As for latency, I really don't see the problem. If you are using nobdy for tuning, you aren't going to be running a bazillion other apps/plugins that add latency to information you care about for tuning.
                      YMMV, but this is the assumption that really has me shaking my head. In my experience, the constant battle is speed. Take this post and log I wrote on MPG calculation:

                      http://www.mp3car.com/vbulletin/engi...ml#post1368900

                      I just opened the log file again and looked, and I'm pulling 80+ PIDs a second from the ECU. I stretch that into 16 good channels of data (above the Nyquist threshhold for right foot data), by putting some things at a lower priority.

                      The other trick is that I am using a 'push model'. The same hardware can be used in a 'poll model', much like a conventional, basic interface, but throughput takes a big hit. Say 80 down to 40-50. I still hear this referred to as 'fast', because if you swap out the interface, 20 or so is more typical for the vehicle/ECU.

                      20 reads a second may sound like a lot, but it is only a couple of channels of good tune level data (right foot changes are generally considered to be 5-6 Hz events, putting minimum sample rates up at 10-12Hz). And it doesn't even go very far for things like MPG. Let's say there is no MAF sensor, so someone is pulling MAP, RPM, IAT, VSS, and either EQ_RAT or an actual WB channel (if available). That is 4 samples per second which is starting to get pretty low, and the samples are shifted from each other in time, making the general computations less accurate...

                      And that is the fast ECU on a fast bus in my daughter's car. If we move to my wife's car, I can yank about 12 reads a second in push model, and degradation follows the same basic path. But even if we are optimistic and say we only take one order of magnitude, not two, 6 reads a second is a very precious commodity.

                      Perhaps if it is all about application. I typically hear from people doing analysis from the collected data. But when the number one complaint I still hear about is speed, it is hard for me to envision a generally slower resource being subdivided not having similiar complaints.

                      Originally posted by tripzero View Post
                      You can ensure that logging gets a higher priority over say, the plugin that is constantly checking for trouble codes.
                      The problem with that is that not all requests incur the same overhead. If you send out a request for DTCs or snapshot info, you have to wait the maximum interval of time for all ECUs (an unknown number) to replay. You then have to wait the minimum interval (which varies depending on the underlying physical transport) before submitting the next request. So, regardless of how you prioritize, every time such a request goes out, the 'logging' app is going to have a non trivial time gap in sampled data.

                      Originally posted by tripzero View Post
                      My car supports it, but obdgpslogger doesn't. Nobdy can do it though.
                      That sounds neat, but again, I wonder if it is especially trivial. There are two basic models, one would be to offer virtual ports and do intelligent combining. The other would be to offer a new service apps would be altered to utilize. Either way, the goal is for OBD transaction transparent coexistance.

                      There is no PID for 'unlock door'. That is generally a make/model specific transaction put on the bus. If it is super simple, great, just broadcast the message, a blip of utilization on the bus. But sometimes they aren't simple. There is a multi message transaction, using non standard handshaking pairs, or messages that don't follow the CAN OBD-II flow control protocols at all. So pass thru and handshaking filters desired for that make/model specific activity, are often quite different that what a J1979 OBD-II logger is going to setup.

                      Just looking at the one case, deriving the lowest common denominator for pass, block, and handshake masks is not trivial, and can easily end up with virtually no filtering. If you end up filtering at the host end and dispatching based on virtual filtering, communication overhead becomes a very real concern. Let's face it, without device level filtering, it isn't all that practical to fit the traffic from a 500 Kbit network onto an RS-232 connection or, worse, a BT SPP connection.

                      Sorry if I am coming across as only negative. I freely admit that my opinion is heavily shaped from past experience in a more specialized industry sector. But some of the technical hurdles do seem a bit daunting.

                      At least 6 protocols on three different electrical standards as the baseline, combined with ECU specific quirks and general ECU responsiveness issues, then the whole murky world of make/model specific connectivity on top... I can see one of my long time Japanese peers rubbing his neck, inhaling through his mouth, and saying "difficult" even as I think about it.

                      Then again, I can look at Parallels running on a Mac and remember that 'difficult' and 'impossible' are not the same thing!

                      -jjf

                      Comment


                      • #12
                        We may not be arguing the same issue. I think what you are arguing is that obdII over rs232 is too slow to do any tuning-type stuff with any sort of accuracy and in a timely manner. If so, i agree. I'm not talking about obdII specifically. I'm really only talking about the app itself and how it is able to provide the best results regardless of the underlying protocol.

                        Please forgive my relative ignorance on the topic. I'm happy to be proven wrong. I really only know it can work in theory. i'll try to illustrate by example which is completely hypothetical but should be in some realm of sanity:

                        Lets say I have a GM vehicle with GMLAN and GMLAN can broadcast engine rpm at high resolution if you turn it on. Let's also say that I write a nobdy provider plugin that is specific to the GMLAN protocol. If rpm is of interest to me I write my provider plugin in such a way that it tells the ECU(s) to publish RPM data on the bus. The result is, that every subscriber plugin that wants to get rpm data gets it in a really high resolution manner without any code changes.

                        Are there possible drawbacks? I'm sure. Maybe I can't get this high resolution rpm data and the other pids I'm interested in. In which case, my provider will return 0's for every other request. The benefit is, logging will still work (although, will only log rpm), a gauge app will still be able to display the rpm gauge. in other words, I don't have to write yet another application. I just write a provider plugin, and I get all the subscribers that have been written and are relevant for free. This will save developers time and effort and offer a standard way for apps to get their data -abstracting them away from the low-level details of the protocol implementation saving them time. The model doesn't scale perfectly, but it may work in many real world situations where custom

                        Gary has already gotten requests for Logger to be used with the megasquirt, obd-I stuff and others. He's put a lot of effort into allowing you to use obdgpslogger with different protocols via a provider(generator) + obdsim + obdgpslogger combination. This works, but if obdsim or logger doesn't know about a mfg specific data set, it can't do anything with it.

                        The bottom-line rationale is that no app exists that allows me to exchange mfg specific stuff and still use external and existing gauge applications and/or logging applications. nobdy solves that issue and a few more (hopefully).
                        Former author of LinuxICE, nghost, nobdy.
                        Current author of Automotive Message Broker (AMB).
                        Works on Tizen IVI. Does not represent anyone or anything but himself.

                        Comment


                        • #13
                          Hence the fundamental problem of multi-process FE's over multi-threaded
                          openMobile - An open source C# Front End (why choose openMobile?)
                          - Always Recruiting Developers -
                          Like what you see? Donations are always welcome

                          Comment


                          • #14
                            Originally posted by justchat_1 View Post
                            Hence the fundamental problem of multi-process FE's over multi-threaded

                            This is not a frontend specific issue issue... no frontend has all the features someone wants. Read my post above. Even a multi-threaded frontend which access obd2 data blocks other applications from accessing obd2 data. Say I am running OpenMobile which has obd2 features... and I want to run my gauge application. I can't.
                            "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
                            RevFE
                            My Shop

                            Comment


                            • #15
                              Originally posted by malcom2073 View Post
                              This is not a frontend specific issue issue... no frontend has all the features someone wants. Read my post above. Even a multi-threaded frontend which access obd2 data blocks other applications from accessing obd2 data. Say I am running OpenMobile which has obd2 features... and I want to run my gauge application. I can't.
                              Well to that effect your never going to be able to. Third party apps are coded to request one PID at a time, even with a buffer if you don't follow that order your gridlocked.

                              But if you have control over the apps then my point was you can lock a thread not a process. A selective buffer (and can do some asynchronous calls) should be able to take care of an infinite load and still maintain PID priority.
                              openMobile - An open source C# Front End (why choose openMobile?)
                              - Always Recruiting Developers -
                              Like what you see? Donations are always welcome

                              Comment

                              Working...
                              X