>1. Volume up/down [default behaviour now]
>2. Skip forward or back quickly in playlist [newly added option]
>3. Cycle forward and back through visuals quickly ala 2 above
>4. Same for preset stations in Tuner mode
> [i.e. skip forward/back through the presets quickly]

Well, #2 and #4 are exactly the same solution, implemented already, but as a separate main menu item.

The player software does not currently have any way to implement #3 (going backwards through visuals), much as we'd all like to have it.

#1 is already there.

The interface for something like this would likely be just like the current PopUp list, just adding more options to it. Hit the knob, get a popup, scroll to the desired action, press again, and then you're in the "scan forth/back" or whatever action you wanted.

But I will leave this be for now, until the concept and feature list matures a little more. Right now, there's just not enough new capability there to be worthwhile, since most/all of it already exists in a reasonable fashion. But someday..

Meanwhile, I haven't touched my ftp server code since Christmas Eve.. gotta get back to work on it.

-ml

It seems to me that if there is a way to modify the player software to implement the concept of modes (setup and playback) then in setup mode, pushing the knob will repeatedly bring up settings to dial in. If it is in playback mode, pushing the knob repeatedly will bring things up like "Visuals" "Song Scan" "Song Skip" that sort of thing. So if you bring up "Visuals" it pops up a bar graph that looks a lot like "Loudness" except when you twist the knob it spins through all the available visuals. Ditto with songs, etc etc.

Like somebody else said, if you're tweaking settings, you're likely to want to tweak all sorts of different settings. Once dialed in, setup mode can be exited. When you're playing back songs, you're likely to want to do all manner of things related to playback (pick visuals, pick songs, shuttle through a song, etc, etc) and want nothing at all to do with loudness, fader, balance--that stuff is wasted!

Calvin

The player software does not currently have any way to implement #3 (going backwards through visuals), much as we'd all like to have it.

Does the player ever re-read the flash block? If we changed the value in flash would the player ever catch on? It just occurred to me that something like this might allow you to go backwards through the visuals, but more interestingly be a good way to get randomly changing visuals which people have been begging for forever.

Actually there is of course an easier way to change visuals. You would make a lot of people happy if you added the ability to send the visual change IR code every few minutes or at some other interval (can you tell when the song changes as a side effect of the timecodes stuff added recently?). Please?

-Mike

In reply to:

---

The player software does not currently have any way to implement #3 (going backwards through visuals), much as we'd all like to have it.

---

Well something does have the ability to go forward AND backwards in the visuals on the player.
When using the Sony stalk interface [which I have] the push and turn sequence on the stalks volume up/down buttons causes next/previous preset in Tuner mode and next/previous visual in Player and Aux in mode.
[when this knob is turned without pressing it in against the inner ring it does the Volume up/down (only) function]

This handling of the forward and backwards visuals selection may be done in the player itself - which would indicate that the other half of my original post about where the Stalk interface is actually handled - in the kernel or in the player - has sort of been answered and the Player software itself does it [given the current statements made about not being able to send the player a 'go back 1 visual' IR code.].

Still even being able to cycle Forward through the visuals via the front knob would be useful.

Still a question remains can we send the player 'fake' Stalk Interface commands, and if so, then we can implement forward and backward visuals that way can we not?

BTW: I also like the idea of it beting able to switch to another visual [either next or random visual] on either a fixed timer or a semi-random timer.

My original post stems from my belief that the wonderful capabilities of the knob up to now are being sadly underused - such a simple and elegant input device can allow users to do things with a turn of the knob that many button presses would be required any other way and we are not using it to its full potential.

[Seeing what the empeg guys did with the Stalk interface knob gives some idea of what can be achieved but thats only available if you have the tuner and the Stalk].

>When using the Sony stalk interface [which I have] the push
>and turn sequence on the stalks volume up/down buttons causes
>next/previous preset in Tuner mode and next/previous visual
>in Player and Aux in mode.

Great! So just fire up the Hijack "Show Button Codes" screen, and tell us all what code it sends.. then ANYONE can use [ir_translate] to remap it to a standard key! (and plus, I might add something to Hijack for it).

-ml

In reply to:

---

Great! So just fire up the Hijack "Show Button Codes" screen, and tell us all what code it sends.. then ANYONE can use [ir_translate] to remap it to a standard key! (and plus, I might add something to Hijack for it).

---

I tried this, unfortunately this produces no codes - this must mean that the Stalk Control is done directly by the Player software. :-((((

Now, the question is if we could find out how the Stalk Interface is done by the player could we do a similar hack to the RDS hack but feed 'fake' Sony Stalk messages to the Player [and also of course feed the real Stalk messages to the same mappable Interface we have now for the normal buttons and IR codes].

I guess we need the input from the Empeg software guys on this one as this is under the control of the player.
I don't even know how the Stalk is 'read' - does it have its own device or does it share things with the Tuner [and is this controlled via IOCTLs or just by opening and 'reading'].

I suppose the stalk commands MUST come in over the Tuner's serial port, possibly concealed as RDS packets.

Can you hook it up, and watch /dev/rds1 (requires a recent Hijack, and you'll need to create it with: "mknod /dev/rds1 p") to see what happens (if anything) when using the stalk?

-ml

the Sony Stalk commands won't be pretending to be RDS packets as the RDS processing is done within the DSP [Altman (Hugo) told me this about 6 months ago when I asked about the Sony Stalk Interface and RDS Tuner interface and Tuner interface pinouts].

He also indicated that the 'serial' interface between the tuner and player is used for send tuning commands to the tuner module and to get Sony Stalk 'buttons' as well as signal strength information and tuning info.

The Stalk buttons are managed in the Tuner by a PIC Micro and the ADC values read are output to the unit via the serial interface.

So the likely device to read is /dev/tuner as thats where the data will be turning up.

How difficult would it be to 'monitor' the traffic between the player and /dev/tuner? [I imagine a simple trace facility intially - possibly in the kernel that dumps all tuner interface traffic in human readable form to the serial port and from that we can work out whats going on].

No, RDS is totally internal to the player - the tuner just sends the FM multiplex (L/R/RDS).

The stalk commands come in over the tuner module's tty.

Hugo

Hugo,
Are you saying that the Stalk commands are available via the /dev/tuner interface or are you suggesting that we go lower and actually monitor the serial packets coming in on the /dev/ttyS? interface that connects the Tuner to the empeg?

If so, what particular packets on this Interface should be looking for to 'snag' the Stalk Interface packets?
[I know you said the protocol between the tuner module and the empeg is quite a simple one but its never been documented - is this something that can change now the player is EOL?



BTW: Hugo - I apologise for misquoting you about the DSP - yes I recall now that you said that the FM multiplex is processed by the DSP and RDS data is sent to the player software via the /dev/rds0 interface.

>The stalk commands come in over the tuner module's tty.

Do those commands pass through kernel space at all?
If so, where..? I want to intercept them and allow IR translations on them.

Thanks.

ISTR I noted what the packets were in another post. 4 bytes, starting with 02 xx yy (xx+yy) where xx is the shift value and yy is the ADC reading. ISTR, anyway.

I also STR it's 19200, 8n1 on ttyS0(?). Not near anything to check at the moment!

Hugo

Yep, I can confirm this information.

Info I get from my Empeg is as follows:

Stalk /Tuner is on /dev/ttyS0, at 19200 - the Player needs to send some command(s) to the Tuner before this becomes active, don't know what the 'enable' command is.

Each Stalk button sends a 4 byte packet in the format as per Hugos post.

Format is [in hex] 02 XX YY XX+YY where 02 means Stalk command I guess, XX is the Stalks 'Shift Value' either 00 for 'unshifted' buttons [i.e. Volume knob NOT pushed in] and 01 for Shifted buttons [i.e. Volume knob pushed in].

YY is the ADC value for the button being read and it does hover around the number a little [you need to test for the ADC value being between YY +/-F where F is the Fudge factor [around 5-10 for F is I think ok to cater for most Stalk variations].

The last byte is the Sum of XX+YY.

The Stalk Interface sends two command packets per button, once for Key Down and once for Key Released.
It doesn't send any timing info but you could determine if its a 'long' press by timing how long the down packet arrives before the up packet.

Key Release has FF as the YY value in all cases.

You also get a seperate 'key' release packet whenever the shift key is released [with XX being 01 rather than 00 , but YY is still FF].

You can grab Stalk commands from the Interface once the player has been running by stopping the player, then a
od -t x1 -v -w4 (redirect stdin from /dev/ttyS0)
will dump the 4 byte packets to the console as you fiddle with the Stalk buttons.

For the record heres the dump of the packets my Stalk makes the Tuner send to the empeg
:
[with comments about each button just pressed preceding each bunch of packets]

Note: Stalk is mounted on Steering wheel RHS on this installation [i.e. setting in emplode says RHS Stalk].

Off Button is to the Front [facing driver] and ATT button is behind [facing the dashboard]. The 3 buttons I called Front, Rear and Underneath are facing the Driver, the Dashboard and pointing to the floor of the vehicle respectively.

These 3 buttons are un-named by Sony as their exact Function depends on the Sony head unit the Stalk is plugs into.

On the Empeg these 3 buttons perform the Menu, Cancel and Shuffle on/off toggle in that order [i.e. Front button does Menu, Rear does Cancel and underneath button does Shuffle in my setup].

Note: for LHS of Steering wheel Stalk installations - Menu and Cancel are swapped, Off and ATT stay with the button of the same name and the meaning of Vol+/Seek+ etc is reversed [i.e. Seek+ becomes Seek- and v/v when in the LHS Stalk config].

Heres the dump of each button press then release on od format, ignore the address part at the front of each packet thats od showing the current offset in the stream [shows no packets are missing and little else :-) ]

Source button pressed (& released)

0000000 02 00 17 17

0000004 02 00 ff ff



Vol+ pressed (& released) etc

0000010 02 00 85 85

0000014 02 00 ff ff



Vol- Pressed

0000020 02 00 6f 6f

0000024 02 00 ff ff



Seek+

0000030 02 00 5b 5b

0000034 02 00 ff ff



Seek- [RHS stalk]

0000040 02 00 49 49

0000044 02 00 ff ff



Off

0000050 02 00 01 01

0000054 02 00 ff ff



ATT

0000060 02 00 2c 2c

0000064 02 00 ff ff



Front Button [menu in RHS config]

0000070 02 00 3b 3b

0000074 02 00 ff ff



Rear button [cancel in RHS config]

0000100 02 00 9b 9b

0000104 02 00 ff ff



Underneath button [Shuffle in RHS config]

0000110 02 00 b0 b0

0000114 02 00 ff ff



Shift pressed and released [no other buttons used]

0000120 02 01 ff 00

0000124 02 00 ff ff



Shift+Vol+ (i.e. shifted Vol+)

0000130 02 01 ff 00

0000134 02 01 5b 5c

0000140 02 01 ff 00

0000144 02 00 ff ff



Shift+Vol-

0000150 02 01 ff 00

0000154 02 01 49 4a

0000160 02 01 ff 00

0000164 02 00 ff ff



Shift+Off

0000170 02 01 ff 00

0000174 02 01 02 03

0000200 02 01 ff 00

0000204 02 00 ff ff



Shift+ATT

0000210 02 01 ff 00

0000214 02 01 2b 2c

0000220 02 01 ff 00

0000224 02 00 ff ff



Shift+Front button

0000230 02 01 ff 00

0000234 02 01 3b 3c

0000240 02 01 ff 00

0000244 02 00 ff ff



Shift+Rear Button

0000250 02 01 ff 00

0000254 02 01 9b 9c

0000260 02 01 ff 00

0000264 02 00 ff ff



Shift+underneath button

0000270 02 01 ff 00

0000274 02 01 b0 b1

0000300 02 01 ff 00

0000304 02 00 ff ff



Shift+Source Button

0000310 02 01 ff 00

0000314 02 01 17 18

0000320 02 01 ff 00

0000324 02 00 ff ff

Note: there is no shifted Seek+/Seek- as due to the way the Stalk is made Shifted Vol+ is the same as Shifted Seek+ [when the volume knob is pushed in to the shift position it physically locks against the inner ring that has the Seek+/- buttons on it so that the two buttons become one and turn together while shift is held in so it can only report it as one button].

Note that the Shifted buttons produce 4 packets, one for the shift, one for the Button pressed, one for the button release and one for the shift release.

The order of these 4 packets could vary, e.g. if you did the following:
Front button press,shift press,release Front button, release shift you would get 4 packets like this:

0000330 02 00 3b 3b

0000334 02 01 3b 3c

0000340 02 01 ff 00

0000344 02 00 ff ff

So any mapping in hijack needs to handle this situation.
You can also get the situation where the key is pressed [and held] then the shift key is pressed and held, then one key is released then the other - so the order the packets can vary depending on how the shift and other button is pressed and released.

I also think that the shift push then shift release [ie no other key shifted just the shift key is pushed then release] could be used as another button in its own right as its dead easy to do on the stalk and could logically act like a modifier key and be used to modify the behaviour of keystrokes that follow.
Its also easy to detect as the shift pressed and shift released packets arrive adjacently.

If you press two keys [and one of them is not shift] then the button with the lower ADC (YY) value blocks the other button until the lower ADC value key is released and it generates a key release packet for the lower ADC value button just released, then you get the key press packet for the higher key.

So, hopefully all this will lets us do some real hacking/mapping of the Stalk IF when Mark gets a chance.


BTW: I think we need to make the fudge factor (F) for the YY +/- range values configurable as previous stalk users have posted about problems with stalk commands not being picked up by the player in all cases and this has been suggested is due to the variations in resistance that each stalk button naturally has - its a analogue device after all!
Some users may find they need larger values of F.
I would think that only one value of F is needed i.e. the same value is applied to all Stalk ADC values.

Wow, what a post.

Please please please e-mail drakino or someone to get this put up at the developer section of riocar.org.

Got it.

Yup, see that. Cool, thanks.

theres one thing missing from my post [got chopped off by the BBS]. Can someone add this to the copy of the earlier post?

Here is why there is no Shifted Seek+/Seek- buttons but there are shifted version of every other button :

On the Sony Stalk device when the Volume knob is pushed in [i.e. shifted], it physically engages with the inner ring next to the Volume up/down knob which has the Seek +/- buttons on it and the volume +/- button and the Seek+/- button turn as one button until the volume knob is no longer pushed in.

The Shifted Seek/Vol+ actually reports as a shifted Seek+/- button even though I call it Shift Vol+/Vol-

This design of the Sony Stalk means that there are 10 unshifted keys [count them] on the Sony Stalk, but only 8 shifted keys.

Still 18 useable keys plus a modifier [push and release shift button] makes for more potential buttons functions on the Stalk Interface than the original Kenwood remote has/had.

Believe me, the Stalk Interface is just as good as, if not *better* than the remote [even the new Rio one] and I hardly ever use the remote anymore.

There are a couple of things the Remote can do that the Stalk can't but we hope to rectify that real soon now - hence this post and the earlier one.

I think I squeezed it in there... Not sure where you wanted it to go in relation to the other stuff. Plus for some reason if I put it at the end, it's not automatically word-wrapping the text so I had to put it further up. I've seen this happen with text on the BBS as well. I don't know if it's a goofy IE6 thing or what.

Put it after the bold text quoted below and replace the non-bolded text in the square brackets in the original post with the posted text to make it read correctly and put it in context.

In reply to:

---

Note: there is no shifted Seek+/Seek- as due to the way the Stalk is made Shifted Vol+ is the same as Shifted Seek+ [when the volume knob is pushed ...]

---

Okay I think I got it. Actually with Drakino's permission I would like to re-organize the developer info section a little bit so things are easier to find. Two somewhat redundant software sections, two somewhat redundant hardware sections, and a "miscellaneous stuff" section isn't ideal, methinks.

Cool, I like that idea. It needed the re-org.

Hi.

You have got my permission to reorganize the contents of the two incase.de-related sections in any way you think would be appropriate. I just added those because I didn't want to temper with someone else's texts without his explicit permission, to I left the other sections alone.

However, I am not pleased that you did not contact me before actually tempering with my material. You should have known better than that.

If you do anything else with my content without informing me at least within a few hours of the actual change, I will really get angry about that.
Those sections weren't named with the tag "incase.de" in their respective names without reason. They were named that way because I felt responsible for them (even if I didn't have as much time to spend maintaining them as I would have liked).

cu,
sven

Sven,

I have to say I am rather surprised by this reaction. If you hadn't noticed, I tried to give you full credit for the information you added in the tagline of each section ("Contributed by..."). Drakino gave me the go-ahead to reorganize things and I didn't want to have to contact 15 different authors to see if it was okay if I simply moved their material somewhere else. I didn't take any credit for your sections, nor did I change any of the content. I hadn't finished reorganizing things, so I think I might have not gotten to one or two of the sections for which you were responsible, but I have it all written down on a sheet of paper here, and it's on my list.

The section is still evolving and I was just trying to move things around. I thought as long as I gave you credit, there was no need to ask permission simply to move it to another section. I apologize for this oversight and I'l try to ask next time.

But really I thought that once someone contributed something to riocar.org, it was somewhat public domain. I at least tried to give you credit, and I'm sorry that wasn't sufficient.

Hi.

But really I thought that once someone contributed something to riocar.org, it was somewhat public domain. I at least tried to give you credit, and I'm sorry that wasn't sufficient.

Don't get me wrong, my previous message was probably a bit too harsh, but mainly I am concerned that you took my work apart: The developer info that was collected under the two main groups of hardware- resp. software info (provided by www.incase.de, as stated in the groups' names) was pretty much my work, even if I "only" collected those infos from the BBS, from available sources and some emails. Now you took those collections that I created apart again, without asking for my permission.
See, I contributed those collections to the riocar.org site as they were (and sharing most of the HTML sources with my own homepage at www.incase.de) because drakino asked me if I would take responsibility of the developer section of the BBS. I agreed to that request, and now (without any direct notice to me), this responsibility is suddenly taken away, and my previous work <irony>all messed up</irony>.
I don't have any problem with you taking over some (or even all) responsibility of the developer section (mainly because I don't find enough time to work on it), I am just a tiny little bit pissed because of the way it happened. That isn't exactly your fault.
In other words: I would be thankful if you would actually reinstall some reference to my homepage again, at least on those FAQ entries that are already marked as "contributed by Sven Müller". Other than that, please just keep me informed if you change any content that I created, and everything is fine.
Anyway, your reorganization of the developer section seems to be well thought about, and pretty clean. Keep up that good work, and if I can help you in any way, just ask. If you find some errors that are in my texts, please inform me of those, so that I can also fix my homepage accordingly. I don't have much (sometimes not even little) time to spend on that, but it should be enough time for a little fix-up here and there.

cu,
sven

Sven,

You haven't been demoted to anything, and I haven't been promoted to anything. I was simply given access to add some information I had researched, and when I couldn't figure out where to add my own information (two software sections), I thought it could benefit from some re-organization. So your statement that some responsibility has been taken away from you and somehow given to me is incorrect. I'm just trying to help out.

Look, you've contributed a LOT of well-organized and valuable content, which is why I didn't change any of it, and credited you. I don't want this to leave a bad taste in your mouth, and I will happily add your site's URL to each of your contributions (actually I just did.)

Let's drop the politics here, I wasn't elected the Grand Master of the Developer Section, I just wanted to contribute, and had some free time over this past weekend. As you get more free time, feel free to add more stuff, or move anything around that seems illogical. I just wanted to see what I could do to make things easier to find. Hopefully some of these newbies who might be future Empeg hackers will have easier access to the infomation than we had when we were learning the ropes. That's what it's all about, right?

Oy, I didn't know this would turn into a mess like that, but it looks like it was worked out as well by the time I got here.

I'm making it official policy now to give credit in any of the sections like the FAQ, Developer Info, etc... Link to relevant posts over here if necessary, but at least have a name.

Sven, you still have full access like you did. I recently gave yn0t access so he could add some info. He reorganized the area, I looked it over, and approved it. I appologize for not thinking to consult with you as well on this. Mark Lord also has access, so that way he can add any info he wants to, if the Hijack development ever slows. (The admin side of riocar.org is definitly not set up for easy, quick updates). Other admins include Rob, Hugo, and Richard L. If anyone else wants access, consult me via e-mail. If you are not well known by the community, please post info here, and one of the admins can then transpose it over to the site.

I definitly wanted RioCar.org to have several key admins, not just myself. This way, the site won't suffer the same "information rot" that overtook empeg.mars.org. I am working from time to time on a new riocar.org that hopefully will have user submittions for the FAQ and Developer Info sections. This should increase content without increasing the admin count to a huge amount.

Hi.

Oy, I didn't know this would turn into a mess like that, but it looks like it was worked out as well by the time I got here.

Right. Let's just get on with the work and put "the politics aside" like some valuable person said before.

I was just a bit frustrated about the way this happened, but I'm over it now, thanks to the great work Tony did with the reorganisation. I will hopefully contribute some more information to the developer section soon, and if all goes well, that will even include a compile-by-mail service (that would even allow for more complex projects that require the use of makefiles) run on my home Linux server.

cu,
sven
(now returning to that damned kernel compile that doesn't seem to work right).

a compile-by-mail service ... run on my home Linux server

Don't bother. So far, only one person has taken me up on my shell account for cross-compiling yet. And he's the one that spurred me to do it in the first place. Maybe I'll bump it up to the top to make sure that folks didn't miss it.