New wiki and manual has launched! Check it out at http://wiki.speeduino.com
For anything you'd like to see added to Speeduino
User avatar
By garcia w
#40327
This is the best News am so happy :D .
@realdashdev if you guys could add in speeduino specific code into RealDash would be Great.
While there are work arounds using legacy serial 'a' to connect Speeduino serial3 to RealDash and still be able to use Tunerstudio at the sametime. "Which am doing right now"
It does require firmware modification everytime a new firmware get realeased and becoz some data ports are specific to megasquirt. To get some Speeduino data visible you have port data to unused megasquirt ports since there no megasquirt XML file .which is very time consuming and frustrating, for an average user "forget it"

Think just like megasquirt using 'a' command
For Speeduino using 'n' or 'A' command would be great
Then port in all the OutputChannels from speeduino.ini , definitely including auxin but be Great asset here as well.

I really like the RealDash app I use it a lot I have a 9" head unit on the way to use in the car as a
main full-time dash with RealDash. I so excited I hope this get done sometime soon.
Thanks
By GhjEng
#40329
using legacy serial 'a' to connect Speeduino serial3 to RealDash and still be able to use Tunerstudio at the sametime.
Yep, that was the bit I was trying to get sorted for my project by adding a "Y" request... or by pulling a pin low to trigger comms... wasn't aware the background work was happening though, so very excited for those updates :)
User avatar
By realdashdev
#40330
GhjEng wrote:
Mon Jan 13, 2020 7:13 pm
Any idea on when this will be complete by? Just weighing up whether to wait, or if I should do my own code changes for the project I'm busy with now...?
I think I can make a working prototype in about one day as soon as we agree what is the best way to implement the integration.
By dazq
#40332
realdashdev wrote:
Tue Jan 14, 2020 7:07 am
GhjEng wrote:
Mon Jan 13, 2020 7:13 pm
Any idea on when this will be complete by? Just weighing up whether to wait, or if I should do my own code changes for the project I'm busy with now...?
I think I can make a working prototype in about one day as soon as we agree what is the best way to implement the integration.
The n command would be the way to go to request from secondary serial.
The response list will be growing over next few months to provide all the realtime data that is present on serial0 currently and a few extras too. Can these be added by us as they get included or do you need to do that?
Else you can start now with what is present.

I am still working on the TS ide side of serial and can broadcast (takes far longer than the actual code ever does!!! ) No timescale on that sorry , as soon as I can 😋
User avatar
By realdashdev
#40333
dazq wrote:
Tue Jan 14, 2020 1:14 pm
The n command would be the way to go to request from secondary serial.
Where I can find the specification on how 'n command' works and what is the structure of the replys? There was a link provided earlier but I could not find anything related to 'n command'
By dazq
#40334
realdashdev wrote:
Tue Jan 14, 2020 1:26 pm
dazq wrote:
Tue Jan 14, 2020 1:14 pm
The n command would be the way to go to request from secondary serial.
Where I can find the specification on how 'n command' works and what is the structure of the replys? There was a link provided earlier but I could not find anything related to 'n command'
n command hasn't been officially released yet hence not in the wiki
But
Response to a n is
n (single byte)
0x32(single hex byte)
Then the number of bytes being sent(single byte)
Followed by the bytes of data.

Note the transmission of ox32 is specific to a full data stream. A different value being sent denotes a different function .

As I say it's not officially released yet as it may be subject to some tweaking , this mainly has to do with additional data and potential order changes. My feelings are that the order of data for n will be the same as that used by TS (or see comms.ino) and the additional data will be added to the end of that list.
I will be putting in a pr over the next few days to that effect to use that list.

Can your software have a selection option where you can choose format type?eg speedy from serial0 or serial3 or speedy can. ?
User avatar
By realdashdev
#40345
dazq wrote:
Tue Jan 14, 2020 1:55 pm
Note the transmission of ox32 is specific to a full data stream. A different value being sent denotes a different function .
...
Can your software have a selection option where you can choose format type?eg speedy from serial0 or serial3 or speedy can. ?
And by 'full data stream' you mean bytes specified in here as 'The Realtime Data List' ?: https://speeduino.com/wiki/index.php/Se ... _interface

There it says 'BIT 0 - currentStatus.secl' does the BIT mean BYTE? Otherwise its quite confusing.

Sure, we can implement multiple protocols, but lets start with the one that would benefit most of the Speeduino users.
By dazq
#40348
Yes that is a typo, should read byte.

That list is what A and n currently transmit.
'A' will remain with that list you linked to as an ongoing legacy list for current users.
'n' is going to change and to use the list that TS gets sent along with the extras needed.

I wonder perhaps you should make a setup for using 'A' command on serial3 as that is fixed and not changing.
Then when work on n Is finished and the list released a n version could be created?
User avatar
By garcia w
#40355
dazq wrote:
Wed Jan 15, 2020 1:55 pm
Yes that is a typo, should read byte.

That list is what A and n currently transmit.
'A' will remain with that list you linked to as an ongoing legacy list for current users.
'n' is going to change and to use the list that TS gets sent along with the extras needed.

I wonder perhaps you should make a setup for using 'A' command on serial3 as that is fixed and not changing.
Then when work on n Is finished and the list released a n version could be created?
I think that's a Good idea aswell @Dazq
(Using 'A' command on serial3 'A' list will be Really Great start. Since it already have majority of the stuff we need to monitor.
User avatar
By realdashdev
#40386
Allright, agreed. I will implement the 'A' protocol and push a Beta to Play Store. There will be a delay of few days. I have to publish the 1.6.6 first as it contains fix for map tiles not downloading which is critical. I will then push 1.6.7 beta containing the Speeduino 'A' protocol. I'll post here when Beta is available.
  • 1
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
Speeduino PCB problem?

Yeah this behavior is almost always down to a shor[…]

Alright here's a video of the problem that isn't p[…]

Boosted 1970 VW Bug UA4C

Hi to all, I was running a MS-2 on my bug since 2[…]

I took some old controllers apart and noticed they[…]

Still can't find what you're looking for?