Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 24

Thread: Mac based software - Bribes and Bounty!

  1. #11
    Variable Bitrate NeonDev's Avatar
    Join Date
    Feb 2008
    Posts
    431
    I'll write it in my will to have the NBB source released.
    I wouldn't get your hopes up for a whole lot of comments in it tho.

    right now I am working on V2 of the NBB SDK which allows 3rd parties to make just as feature rich modules as I have made for it. It includes all my subclasses for dynamic color changing and all that other good stuff. The biggest problem is writing the documentation. I can give you the SDK now but no programmer will be able to use it without directions.

    I think you are getting close to finding an approach that will get you what you want tho. I myself am not willing to start all over on a brand new FE, I have put too much into NBB, and it is obviously important to me. I also don't feel like releasing my source for the core application. However, what I would do is accept a bounty to create an open source module or two for NBB. the biggest thing holding me back from developing OBD2 and GPS/nav modules is the lack of hardware I have. I have no carputer I have no GPS module I have no OBD2-to-serial-to-USB capability. If somebody donated money or hardware those things would get done sooner rather than later. that is why I am working on an XM radio module for NBB; I have no interest in XM radio myself, but somebody who did sent me the hardware and now I have successfully interfaced with it and have only to write a module. the hard work on that end is done it is just time that I am finding hard to come by.

    just remember I am only one person and can only do one thing at a time, and most of the time that is my actual job that puts food in my mouth. Give me the hardware/money and point me to some documentation on the subject and I'll get you what you want. its just a matter of time.

    Navigation solutions (especially good ones) are very complex.
    what i suggest (assuming an NBB module solution) is somebody grab the mac compatible guts out of the best open source mac or unix compatible navigation program and bundle it into an open source navigation module. I will even help
    check us out at: www.neonboombox.com

  2. #12
    Newbie
    Join Date
    May 2008
    Posts
    45
    Quote Originally Posted by NeonDev View Post
    just remember I am only one person and can only do one thing at a time, and most of the time that is my actual job that puts food in my mouth. Give me the hardware/money and point me to some documentation on the subject and I'll get you what you want. its just a matter of time.
    Of course. Feature creep is the hardest thing to overcome, especially when working on a successful project by yourself. It's inevitable that all software will reach a point of emacs syndrome (that is, you attempt to include everything AND the kitchen sink).

    An obvious solution to this is doing exactly what you've elected: Develop the core, and the "add-ons" that are low hanging fruit (eg, those you have the hardware for), leave the kitchen-sink to plugin/mod makers.

    Bear with me on the next part, it's a bit of a brain dump:

    Objectively speaking, what stops you (or someone else in your situation) from using the community support you've received on your closed source app, and turning it into shareware, or worse yet, commercial? Those who have helped the overall end-product by donating money/hardware/code, end up with a piece of software they have no stake or control over.

    Pragmatically speaking, the only real solution with a closed source "core" is to release these "sponsored" plugins under some form of license that is agreeable with those who sponsored. In the event that the "core" application does change license/cost, those who contributed (in some fashion) to the creation of the add-ons aren't left feeling "out in the cold".

    Of course this is solely my opinion, and I wouldn't dare suggest that you (or Jirka, or anyone else) feel obliged to do it this way.

    Frankly, I am more than happy to purchase the first "decent" Mac based system that comes down the pipe. I just don't see any available right now. And understandably so, the OSX space for this niche market just can't be a profitable platform for 99.9% of the companies out there. OEMs don't want to mess with Macs because of pricing and distribution issues, most users probably feel the same, and devs face some real challenges in terms of COTS hardware compatibility / community interest.

    Which is how I end up feeling that the only way this is going to happen is through a community driven effort *even if it's towards a commercial application*.

    So, after all this musing, meandering and rambling....

    Here is my suggestion, based on all the excellent feedback I've gotten on my (flawed) idea:
    Developers: Create bounties for your existing platforms.

    NeonDev, you mention that you are interested in working on OBD-II and GPS, but you require the hardware to do so. Understood.

    I will buy you an ElmScan/5 Bluetooth w/ USB/RS-232 converter, provided I can impose a few requests:

    When you are able to achieve your goal of an OBD-II plugin/interface, the source for that plugin is released under GPLv3*

    I also think it would be great if you created some sort of donation page so that people like myself can help contribute money towards other hardware/tools required for your ongoing development. Hopefully, work resulting from these community contributions would be similarly licensed.

    Quote Originally Posted by NeonDev View Post
    Navigation solutions (especially good ones) are very complex.
    what i suggest (assuming an NBB module solution) is somebody grab the mac compatible guts out of the best open source mac or unix compatible navigation program and bundle it into an open source navigation module. I will even help
    The maemo platform has cut a wide swath on these types of projects. MaemoMapper was the second "major" attempt, and it is easily the most prolific. Most efforts after it's release seem to copy it, and I think it would probably be a good starting resource.
    It's likely not terribly portable due to it's heavy reliance on the Nokia tablets Hildon/GTK, but I imagine the core math and tiling code is sound.

  3. #13
    Variable Bitrate NeonDev's Avatar
    Join Date
    Feb 2008
    Posts
    431
    I have no intention of going commercial with NBB. I don't want to go "shareware" but if i did I would be sure to give anybody who as donated hardware or a fair amount of money would get free lifetime upgrades. My favorite choice is to keep what I do closed as donation ware that is free for anyone to use. I don't feel like donation ware is compatible with open source because a huge part of supporting it comes from feature requests (i.e. i will give you $X to make your app do this) and if it is open source there is a chance somebody will come along and harvest my hard work and repackage it because they don't like the interface or whatnot.

    I am not in this to make huge amounts of cash. I am in it cuz Its what I will want when I finally get my carputer and nothing existed that fit my needs. Donations are the best thing for the community IMO. I feel like that makes the most of everything. It means nobody has to pay if they don't want to but they can donate to get features added.

    i can promise that if the donors for such work as GPS/OBD2 wish it, I will release the source to those modules/classes/functions under whatever license they want as long as it doesn't prevent me from using it while the rest of the app is closed. I can even distribute the app and the modules separately if needed
    check us out at: www.neonboombox.com

  4. #14
    Newbie
    Join Date
    May 2008
    Posts
    45
    Quote Originally Posted by NeonDev View Post
    I have no intention of going commercial with NBB. I don't want to go "shareware" but if i did I would be sure to give anybody who as donated hardware or a fair amount of money would get free lifetime upgrades.
    This is great news!

    Quote Originally Posted by NeonDev View Post
    My favorite choice is to keep what I do closed as donation ware that is free for anyone to use. I don't feel like donation ware is compatible with open source because a huge part of supporting it comes from feature requests (i.e. i will give you $X to make your app do this) and if it is open source there is a chance somebody will come along and harvest my hard work and repackage it because they don't like the interface or whatnot.
    This is an excellent point, and all the more reason to keep the "core" (eg Front-End) closed.

    Quote Originally Posted by NeonDev View Post
    i can promise that if the donors for such work as GPS/OBD2 wish it, I will release the source to those modules/classes/functions under whatever license they want as long as it doesn't prevent me from using it while the rest of the app is closed. I can even distribute the app and the modules separately if needed
    Works for me. I see no reason that you couldn't distribute a GPLv3 licensed binary lib/plugin with the NBB itself, provided a download link for the source was available for the GPL'ed code itself.

    NeonDev, if you're game, my offer stands for the Scantool. Drop me an email
    hanzo[isat]freezerpants[nospamdot]com

  5. #15
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,364
    Blog Entries
    2
    I think the right thing to do here is create modules for bounty. Car Front End, NBB, and AMP 2 all have plug in capability.

    What would speed development would be open source modules that could be added in to any Mac app. For example:

    1. A module for XM that works with a serial-virtual com port
    2. A module for Sirius that works similarly
    3. A module that interfaces with GPS and reports lat/long, speed, ETA's, etc.
    4. A module that interfaces with and LCD/VFD display to allow output of data to these devices
    5. A module that interfaces with an Elm Scan OBDII connector and the car
    6. A screen dimming module that works like Shades

    Stuff like that. Make those open source and let developers plug them in to their apps.

    Hell, if you included applescriptability in them, most anyone could use standalone versions of them without killing themselves.
    Quote Originally Posted by ghettocruzer View Post
    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

  6. #16
    Variable Bitrate NeonDev's Avatar
    Join Date
    Feb 2008
    Posts
    431
    @bugbyte that is absolutely the way to go IMO. if people want to start a new FE just because no current FEs provide a certain feature nothing will ever come about but a collection of FEs with many different features but none that have even close to everything.

    since the majority of FEs have plugin capability and are all OS X based there is little stopping somebody from writing the code that does all the work and "porting" it to all the different FEs. obviously there are likely some exceptions but I'll wager an OBD2 or GPS module could be ported fairly seamlessly across the board. If i end up being the one who writes it driven by donations then I have no problem with the code ending up in any of the other FEs at all.

    just somebody needs to get the ball rolling. right now I am swamped at work and I am obligated to finish the XM module before moving on to the next thing.

    @hanzov
    I will gladly take up the offer if it still stands after I finish the XM module. I feel more comfortable taking the initiative on OBD2 then navigation since I have no idea where to even start with navigation.

    couple of questions. how does the scantool interface with the mac? what drivers are needed to communicate with it? do you have or know where I can find good documentation on OBD2 communication?

    If you end up sending it to me and I can't do anything with it I will send it back
    check us out at: www.neonboombox.com

  7. #17
    Newbie
    Join Date
    May 2008
    Posts
    45
    @NeonDev/BugByte

    Well said both. This is exactly my frustration, picking through the forum is a virtual graveyard of fancy interfaces, interesting ideas, and a lot of vapor and abandoned code.

    Hence my push for OSS/GPL type plugins/modules.


    Quote Originally Posted by NeonDev View Post
    I will gladly take up the offer if it still stands after I finish the XM module. I feel more comfortable taking the initiative on OBD2 then navigation since I have no idea where to even start with navigation.
    Of course. Let me know when you are ready to take it on, and I purchase it.

    Quote Originally Posted by NeonDev View Post
    couple of questions. how does the scantool interface with the mac?
    I don't specifically know what the USB/RS-232 cable offered by Scantool.net is based on. When I bought my elmscan/5, I opted for the straight bluetooth version.

    However, connecting it to my mac was fairly painless, I used a USB/RS-232 adapter I had laying around (actually, I have several) based on the Prolific PL-2302 chipset, which is exceptionally well supported. I've been able to source these cables locally for about $10 USD.


    Quote Originally Posted by NeonDev View Post
    what drivers are needed to communicate with it?
    Just the ones available at that link

    Quote Originally Posted by NeonDev View Post
    do you have or know where I can find good documentation on OBD2 communication?
    That's a bit trickier. Reading off ODB-II is pretty straightforward, as I understand. (Warning: I may not be 100% correct with what I am about to say...don't hold it against me)
    I found some pretty basic information on working specifically with the ElmScan here. As you can see, it's not terribly complicated to work with.

    As for dealing with the data itself, it looks like the I/O is based around simple request/response, EG request a PID for a value you would like (Vehicle Speed), it returns an integer in a pre-determined range, which would then need to be parsed and applied to the GUI graph/control.

    I believe this list on Wikipedia is quite comprehensive, and presumably accurate.

    There are a number of quick-n-dirty OBD-II scripts that will do request/parse data, pyOBD might be worth looking at as well. It doesn't really tell you much info, it's more for sorting out the cause of MIL code, and it's also fairly old.

    Quote Originally Posted by NeonDev View Post
    If you end up sending it to me and I can't do anything with it I will send it back
    While I am confident this will be "low hanging fruit" for you, in the event that it proves to be a stumper, I would rather see it "paid forward" to another dev with the chops to take on the challenge

  8. #18
    Newbie
    Join Date
    May 2008
    Posts
    45
    Guess I should look before I speak.

    The cable available from Scantool.net is based on the Prolific PL-2303 chip, which has Mac drivers, so in the best laid plans it should be largely the same as the PL-2302

  9. #19
    Variable Bitrate NeonDev's Avatar
    Join Date
    Feb 2008
    Posts
    431
    hey as long as there is an intel mac driver that can send and receive data I see no reason why I won't be able to do something for the community. wish I could start now ;-)
    check us out at: www.neonboombox.com

  10. #20
    Newbie
    Join Date
    Nov 2008
    Location
    Birmingham, UK
    Posts
    3
    I've been lurking on and off mp3car.com for years now, and finally I think its time to post.

    I too will offer a small token of monetary value (aka, cash) to see this brought to fruition. I've been trying to build ScanTool.net on my mac for a little while now (and some very smart people have given me a hand too) but seem to have hit a brick wall, whenever it tries to connect to a serial port it segfaults.

    I'm using a USB to OBD2 adapter I got on ebay, auction number 290270570782, after plugging it into my 1.5Ghz Alu. Powerbook, it failed to work initially, but I checked system profiler and it listed the device as "FT232R USB UART", a quick google later and I found drivers for it

    So I've got it installed, I've symlinked /dev/ttyS0 to /dev/usb.serial-blahblah, but whenever ScanTool.net tries to open the serial port (or any for that matter), the software segfaults. Even if I change the COM port (which Allegro should reassign to /dev/ttySx automatically, so COM1 is /dev/ttyS0) it still crashes. I've confirmed its this by the following;

    1. log.txt comprises of:

    Thu Nov 13 23:40:29 2008
    Version: 1.08 for DOS

    Initializing All Modules...
    ---------------------------
    Initializing Allegro... OK
    Installing Timers... OK
    Installing Keyboard... OK
    Installing Mouse... OK
    Loading Preferences... OK
    Trying Windowed Graphics Mode... OK
    Loading Data File... OK
    Initializing Serial Module... OK
    Opening COM1...
    2. When it crashes, I see the following in the crash report;

    Thread 1 Crashed:
    0 ScanTool 0x0000c940 comm_port_set_baud_rate + 0 (crt.c:355)
    1 ScanTool 0x0000409c open_comport + 80 (crt.c:355)
    2 ScanTool 0x000034a4 init + 1184 (crt.c:355)
    3 ScanTool 0x000035fc _mangled_main + 116 (crt.c:355)
    4 ScanTool 0x0000c17c call_user_main + 68 (crt.c:355)
    5 ScanTool 0x0000c1c0 +[AllegroAppDelegate app_main:] + 64 (crt.c:355)
    6 com.apple.Foundation 0x92bf7118 forkThreadForFunction + 108
    7 libSystem.B.dylib 0x9002bd08 _pthread_body + 96
    Now I'm not quite sure what #2 means, I know the basics of threaded process execution, and I can tell that it tried to set the serial port baud rate and then try and open it.. but after that it gets hazy.

    Anyone want to take up the rope?

Page 2 of 3 FirstFirst 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •