Is there a way to ask a MIDI device for its current timecode value while it is stopped? Specifically, I want to poll Pro Tools for its current MTC value (via the macOS Audio MIDI Setup Utility, IAC bus). The only way I've been able to come up with is to send a play command, immediately followed by a stop command. But I'd like to find a way to do it without moving the bus. I've tried sending "pause", "reset", "shuttle", and "chase" commands, but nothing will get Pro Tools to send the current MTC time value besides "play." Hoping to not have to use the old HUI protocol (if it even works with PT anymore). Thanks
The MTC specification says that Full Time Code messages are sent "when equipment needs to be fast-forwarded or rewound, located or cued to a specific time". This implies that no messages are sent if the time has not changed.
So there is no standard way.
Related
I'm trying to get a Raspberry Pi with a 4" touch screen setup to wardrive and capture some WiFi signals. The piece that is giving me issues is getting the GPS working.
I'm trying to use a module that came with Microsoft Streets & Trips I got a long time ago.
lsusb shows the device as "Bus 001 Device 007: ID 1546:01a5 U-Blox AG [u-blox 5]"
dmesg | grep tty shows:
[ 8.276615] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
[ 344.931792] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
I do see a data stream if I issue cat /dev/ttyACM0
sudo gpsd /dev/ttyACM0 -F /var/run/gpsd.sock and then gpsmon /dev/ttyACM0 gives the following:
But then when I try cgps -s I get:
I seem to be getting some data but no lat/long/time data.
Should I conclude that this GPS module is not supported?
Are you sure your receiver has a satellite fix? Also, you have a log of the GPS data stream? Do you know what specific model receiver you are using?
From your first screenshot it looks like you are definitely receiving data from the GPS, as it's recognizing several different NMEA sentences. On top of that, the first screenshot shows what seems to be a valid GPGLL sentence (I haven't confirmed the checksum):
$GPGLL,,,,,224538.00,V,N*40
My initial hunch would be that the GPS receiver does not have a satellite fix. This is based on
Empty GPGLL sentence. The only populated fields in the above sentence are the UTC time and Status fields. The Status value is V, which means the data is invalid.
Status NO FIX in the second screenshot.
The various boxes in the first screenshot give me the impression that GPSD is correctly parsing the various NMEA packets. For example, the GSV box lists various satellites in view.
The lsusb output reports the device as a u-blox receiver. U-blox receivers generally have solid support from GPSD, so I'd be surprised if this receiver isn't supported (but anything is possible). Without knowing the specific model it's hard to say anything definitive.
I've only worked with a couple different receivers, but my general experience is that when they don't have a fix on startup they'll send empty/partial packets. And the date/time data in those packets is probably due to a Real-time clock (RTC) on the receiver. RTCs are common on GPS receivers as they often drastically improve the Time To First Fix (TTFF). So it makes sense that you have a time, but it's marked as invalid.
Recommendations
The fact that your receiver is reporting satellites in view (though none are being used) and that the Status is NO FIX is especially strong evidence to me that your receiver probably just doesn't have a fix. Try moving it to somewhere with a better view of the sky. Also ensure that if it requires any kind of external antenna hardware that you connect that. Lastly, you might have to wait awhile to get a fix. If it's been awhile since you've used the device you could be looking at a cold start with a TTFF of upwards of 10-20 minutes.
My problem is related to SIM800 connection messages.
I use the module with STM32 developlment board. Sometimes module is reporting SMS Ready and Call Ready messages respectively. When I start to send AT commands to the module, it may send these messages (it doesn't happens all the times).
However, the commands I previously sent are apparently unrelated (for example HTTP commands), and SMS Ready / Call Ready messages is coming while they are not expected.
Because of this reason, Keil is reporting "Can not access" message in the debug session. Is it possible that disabling these messages when the connection is established? Or it means that module has an unexpected reset?
According to SIM800x modules AT commands guide, SMS ready and Call ready are URCs (unsolicited result codes) sent at startup as soon as the capabilities to deal with SMS and to perform calls respectively are correctly initialized and available.
So this is the first bad news for you: if you see them it probably means that your device reset due to a bug or as a consequence of one of the commands you previously provided.
The second bad news is that on the AT command guide linked above there's no mention of the capability to disable SMS Ready URC.
There's fortunately at least a good news: Call ready can be disabled by means of AT+CIURC command:
AT+CIURC (Enable or Disable Initial URC Presentation)
Syntax: AT+CIURC=<mode>
<mode> : 0 Disable URC presentation - 1 Enable URC presentation
Note: When module is powered on and initialization procedure is over URC "Call Ready" will be presented if is 1.
The guide also mentions the fact that this setting is saved in the profile area. So, in order to make sure it is persistent to reboot, after issuing the command store active profile:
AT&W
OK
For me, receiving a lot of messagens Call and SMS ready was a problem on current not enough to keep the module working.
(You can check it too watching the led blinking, if it blinks 6/7 times and stop for a while and restart over again, you have the same problem)
Just to SIM800 keep working is necessary at least 700mA.
Ps.: You can connect directly to your battery 18650 (3.7V-4.2V).
If you are using TP4056 module, you must remember there is 1A max current. try to connect in parallel more than 1 TP4056.
My first question on here so I'm not sure if that's the right forum.
I've connected with my car's ECU K-Line through FTDI-OBD cable and terminal. Found it's something like KWP2000 but without preinit hassle. I just send it commands on 9600 baud, even parity, 1 bit stop and got a reply with VIN number. When I try to send same command with ELM327 it doesn't work and I believe because of ELM adding something, either initialisation of the KWP or adding some checksum or additional info and it doesn't work.
I've already tried using
ATSP5
ATIB96
ATBI
And it still doesn't respond eg. VIN message from sending same command.
My point is to get to secret sensors data from $21 because there is a little info in regular Mode01. And I want to use ELM327 because I wanted to use Android phone to display the data.
I've got a Behringer X32 rack, which uses an extension of the OSC (Open Sound Control) protocol. This particular rack communicates via UDP packets on port 10023. A fellow named Patrick Maillot actually has some pretty extensive albeit unofficial documentation of the protocol, including multiple executables you can download to interact with the system (outside of the official Behringer apps).
What I would like to do is pretty simple, though I'm having a hard time getting up to speed with this. I want to be able to mute and subsequently un-mute Mute Group 1 on my device. The mute group is already set up; all I want to do is utilize the protocol to either activate or deactivate it.
I can successfully connect to the rack using the X32_Command.exe program. But wading through the documentation, here's what I came up with as my best guess for which commands I should be sending:
/config/mute/1/ON
/config/mute/1/OFF
However, I don't think I have the syntax right (or maybe I've just got the wrong set of commands altogether), because those don't seem to do anything. In the X32_Command.exe console application I appear to receive the following responses when issuing those commands, respectively:
->X, 20 B: /config/mute/1/ON~~~
->X, 20 B: /config/mute/1/OFF~~
However, nothing actually happens on the rack. The mute group isn't affected at all when I issue these commands. How do I get this working? What am I doing wrong?
Just saw this (better late than never). The correct syntax for X32_Commmand.exe would be (as stated in the documentation):
/config/mute/1 ,i 0
/config/mute/1 ,i 1
For a toy project I want to find out if a mobile phone is connected to gsm or not. So I thought "Okay, let's use my local sip provider and see".
But in both cases, the thing goes like this:
I send an INVITE
0 s: I get a 100 Trying
5 s: I get a 183 Session description
I get an audio stream, in the one case with the ringing, in the other case with a "The person you are calling is…"
If I wait long enough (~ 40 s), I get a more appropiate status code like 180 Ringing.
Audio analysis is not an option, really.
Any hints on where to go now?
(I used twinkle for testing and a local german sip-provider.)
This issue is endemic in the way telephone networks work, and is not specific to SIP or IP. It's why, when you place a call to another country and the number is busy, you might sometimes hear your local country's busy tone, or you might hear a different busy tone that comes from the other country. In the latter case you cannot detect except by audio analysis, what the problem is. In SS7 and ISDN we speak of Q.931 cause codes instead of SIP error codes, but the principle is the same.
There's an argument to be made for configuring telephone systems to emit status codes instead of audio error messages. For callers using normal phones, the originating switch (the one closest to the caller) can then map that code to the appropriate spoken error message or audio tone. That way, when the call is being placed by software rather than by a person, the software can have access to the actual error code right away.
On the other hand you can also argue for having the remote switch (the one nearest the destination or the one that encounters the problem) speak its own error message. That switch knows best what the actual problem is. For example, a mobile operator can emit a spoken error message saying that the mobile phone you are trying to call is currently out of range. There is no Q.931 code (or SIP error code for that matter) with that meaning. It could return 27=Destination out of order?? Or 35=Destination unattainable?? Both of those codes are so esoteric, who knows what error message the local switch would translate them to (in practice: probably just a reorder tone, which is really user-unfriendly to a human caller). And when you try to map Q.931 cause codes to SIP error codes back and forth, even more information is lost because the codes really don't match up well at all. It's likely to be a much better user experience for the caller if the remote switch just plays back an informative, appropriate, recording which describes the problem.
Since there is this dilemma (arguments on both sides), we can conclude that this will not likely be resolved by completely standardizing on one way or ther other way anytime soon.
Anyway, sometimes this is configurable: your SIP provider may be able to configure your trunk for coded errors instead of recorded messages. If they offer this (some do), it's worth a try to set this option. But results will vary: this option only affects its local behaviour. In general if you want immediately call clearing with cause code and are instead getting a recorded error message from the other end, you will not be able to do anything about it, because the switch that makes the decision on which way it's going to respond is the remote one.
When using the audio message method, a proper Q.931 cause code or SIP error code usually comes eventually (after the recording is finished), but as you point out, it's probably too late by then.